Meeting the Challenge of Vivek Kundra's 25 Point Plan

1 | P a g e Planet Technologies

Meeting the Challenge of the 25

A considered approach to resolving the failings in the way the US Federal Government defines, selects, manages and monitors IT investments.


Table of Contents

I. Introduction ............................................................................................................................ 3

II. Defining the Problem Space ................................................................................................... 3

III. Enabling the Change ............................................................................................................... 4

IV. Consistent, Transparent, Results-based Program Management ............................................ 5

V. Checks and Balances ............................................................................................................... 5

VI. Meeting the Challenge ............................................................................................................ 7

i. Leveraging Enterprise Agreement Assets in Attacking the Challenge ................................. 7

ii. Manage Requirements......................................................................................................... 7

iii. Manage Scope .................................................................................................................. 9

iv. Manage Resources and Monitor Performance .............................................................. 11

v. Manage User Feedback...................................................................................................... 12

VII. A Conceptual Solution Architecture .................................................................................. 13

i. Overlay Process .................................................................................................................. 13

ii. Technical Architecture ....................................................................................................... 15

VIII. Embracing the Challenge ................................................................................................... 15

IX. Conclusion ............................................................................................................................. 16


I. Introduction In a recent memo1 from the Federal CIO, Vivek Kundra, Section A focuses on the need to look

first to services offered on infrastructures not owned and operated by the Federal Government,

collectively termed the Cloud. Sections B, C and D deal largely with the failings in the IT

planning and management processes within US Federal Agencies that have enabled large scale

IT investments to drag on, languish, and ultimately fail at significant cost to the taxpayer. Vivek

leads a call to action. The following paper lays out approaches to meeting the challenges as

highlighted in Sections B,C and D and features tools you may already own to assist with

maturing IT planning and management processes, and leverages the real world experience of

capital planners, enterprise architects, project managers and business managers.

II. Defining the Problem Space The problem at the highest level is that the critical processes that enable successful IT project

delivery have traditionally been disjointed. Business Management, Program Management,

Acquisition, Budget, and Governance processes all require tight integration to streamline the

technology cycle, not to mention the IT delivery function itself. Seamlessly integrated processes

result in a technology cycle that is more agile, delivers IT solutions faster and with a higher

degree of quality and success. However, in order for these processes to be tightly integrated it

requires each of the processes to mature collectively, not independently.

Traditionally, each process is operated by an organizational unit that matures its own process

with little consideration to the impact on, and/or maturation of, other dependent processes.

Federated organizations, timing, various appropriation sources, limited authority, data

verification, accountability, and independent support systems are all presented with their own

challenges and when combined make it that much more challenging for Federal agencies to

mature and integrate the critical processes.

The problem space is complex and requires incremental, measured improvement to ensure

processes are integrated and matured collectively. Defining an approach and developing a

system that impacts any single one of these work streams will not deliver the necessary

improvements nor will it enable the mandated visibility. The solution needs to be able to be

integrated into the work processes and systems of multiple, historically stove-piped domains,

whilst enabling centralized storage and analytics to inform oversight activities.

1 http://www.cio.gov/documents/25-Point-Implementation-Plan-to-Reform-Federal%20IT.pdf

http://www.cio.gov/documents/25-Point-Implementation-Plan-to-Reform-Federal%20IT.pdf


III. Enabling the Change The changes required to mature the processes inherent in Business Management, Program

Management, Acquisition, Budget, Governance, and IT Management collectively and integrate

the processes seamlessly can only be enabled through the consistent application of rationalized

/ normalized resources (technology and people), applied consistently throughout the entirety

of the technology lifecycle. The technology lifecycle, at a fundamental level encompasses

Identification of a business need.

Research into and evaluation of alternative technical solutions.

Selection of a proposed solution.

Application for authority to procure (through IT selection boards or through the use of

discretionary funding).

Issuance of a solicitation.

Evaluation of bids and source selection.

Project commencement / deployment.

Steady state operations.

Migrations/upgrades (potentially)

Ultimately decommissioning and retirement.

Management of a solution from pre-selection through, at minimum, full production

deployment into a steady operating state can only be achieved through cross process

monitoring and measurement. Achieving this application of the management resources

consistently requires a combination of a top-down and bottom-up approach.

The top-down approach requires organization unit /agency buy-in, cooperation, and the

evaluation of the performance of senior leaders based on their ability to drive this maturation.

The bottom-up approach requires an analysis of support systems, alignment of procedures and

timing, and rationalization and verification of the data to be shared between processes.

Federal agencies have options when it comes to enabling the changes required to achieve a

more effective and efficient technology cycle. The common resources and skills required to

transform and execute can either come from internal sources, internal sources with support of

external vendors, or from external vendors managed by internal sources. To determine the

option that is most effective for an organization requires an unbiased assessment of the

resources available to the agency. This organizational assessment is the first step to enable the

change.


IV. Consistent, Transparent, Results-based Program Management Program Management is the common thread throughout the technology lifecycle, from

managing requirements on the front end, managing scope and resources throughout

development, monitoring performance throughout, and managing user feedback once

operational. Each of these activities are not stand alone, nor do they take place at one singular

point in time, but rather each of these works hand in hand and are constantly impacting one

another.

Figure 1: Program Management Functions and the Performance Improvement Lifecycle

The alignment of Acquisition, Budget, and Governance processes with Program Management

creates additional complexities but that can be simplified through clear definition of the hand

offs and timing required. Through the use of technologies that most agencies already own,

forms and workflows can be established to facilitate the hand offs and data exchanges,

notifications, alerts, and warnings can be established to ensure the required timing is being

adhered to, and performance can be measured to further refine the integration.

As Federal agencies undertake the organizational assessment described in Section B of the 25

Point Plan, it is imperative that the maturity of the Program Management, Acquisition, Budget,

and Governance resources be considered as a whole. Incrementally defining and implementing

requirements to integrate each of the processes will produce results quickly in the near term

and consistently over the long term.

V. Checks and Balances Technology programs within the Federal Government often go off track when the appropriate

controls are not in place to ensure consistent and un-biased measurement of program and

resource performance. Through the establishment of a common assessment system designed

to facilitate the Program Management function, it is possible to begin to establish authoritative

Pro

gram

Man

age

me

nt

Manage Requirements

Manage Scope

Manage Resources and Monitor Performance

Manage User Feedback

Pe

rfo

rman

ce

Imp

rove

me

nt

Life

cycl

e OperateImplementInvestArchitect

Select Segment to

Architect

Implement Authorization

Preselect Authorization

Operate Authorization

Decommission Authorization

Select Authorization


data points/sources with clear traceability to programmatic delivery. In addition, it provides the

basis through which individual and group resource performance can also be measured. The key

to truly benefitting from a systematic, data driven approach can only be achieved when we

anticipate that any system of performance measurement will, inherently, be susceptible to

‘gaming’ or manipulation in either inadvertent subtle, or obvious and egregious ways. The

system of measurement and transparency must be designed with checks and balances to

accommodate check for and correct these inconsistencies.

As an example let us examine a common scenario. If an agency decides to develop or directly

hire program management resources, there is inherent risk of program managers “going

native” if they are left to manage their program for extended periods of time. The term “Going

Native”, originating in diplomatic circles, describes a scenario in which a neutral observer

begins to have sentiments of sympathy and alignment to the cause of those being monitored. It

is the reason Diplomatic appointments are changed on a regular basis.

In a program management scenario in which the program manager is inherently responsible for

successful oversight of a program or project to its conclusion, the temptation to report to

management that the program is on-schedule, or to be optimistic about schedule slippage

being recovered by crashing the schedule is extremely high. As a result, it is frequently not until

a program is irretrievably behind that management or executive oversight learns the truth.

To mitigate the “going native” risk, it is necessary to have the program managers manage

different programs on fixed timetable, moving them with a pre-determined frequency. Doing so

mitigates one risk, but also presents additional challenges, in that it requires each program and

each program manager to adhere to a common set of standards and enforceable controls so

that each program manager can be swapped out seamlessly.

Conversely, if the government agency decides to outsource their program management

resources, it requires that the agency be willing to establish the necessary internal structures

and controls. The contract vehicles themselves need to have due diligence applied to ensure

the service levels built into the contracts provide indicators that:

1. The contractors are adhering to agency standards.

2. The contractors are delivering services in accordance with planned cost and schedule.

3. The contractors themselves are not being adversely influenced working so close with

the projects themselves.

Ultimately, Program Managers need to be responsible for helping guide the program towards a

successful outcome. Equally as important, they must be aware of and fully understand the

escalating program issues that could ultimately result in programmatic failure.


VI. Meeting the Challenge Figure 1 on page five, identifies the key work streams within program management and their

alignment with an ongoing performance management lifecycle. Analysis of precisely defined

data points such as milestones in delivery, deadlines, budgetary cycles and fiscal indicators,

(including burn rate) from the project level, understood in the context of an IT program,

enables critical oversight at a project level while also providing the visibility necessary for

managing dependencies and true overarching programmatic performance. Alignment of the

two work streams and the practical unification of their actions through consistent and

normalized data driven project and portfolio analysis is the central tenant that must be

followed if we are to effectively manage the delivery of a continuous improvement of the

services provided by IT. The establishment of a technical solution to centralize the collection of

the data to support the analysis will provide the keystone that supports these program

management functions. Clear visibility into their interactions provides a foundation through

which program management as a whole can begin to mature collectively.

This foundation is imperative to provide the long-term stability on which processes and

procedures can be developed and refined over time. Furthermore, the interdependencies

between each of the program management functions (Requirements, Scope, Resources and

Performance, and Feedback) demand a consistent but flexible central collection node that can

begin with simple milestones and as the IT program management methodologies discussed

within the CTO’s plan are defined by OMB the system can be incrementally improved and

augmented to ensure constancy with the requirements of both legislative mandate and

common best-practice.

i. Leveraging Enterprise Agreement Assets in Attacking the Challenge

Most Federal Agencies have a significant investment in Microsoft technologies acquired

through an Enterprise Agreement. Enterprise Agreements contain a large number of products,

many of which tightly integrate together delivering rich functionality across platforms that can

be utilized either through a web browser or through the Microsoft Office Suite of Products

including Outlook through E-Mail. The interface is familiar to end users and management of the

platform is something with which technical resources have demonstrated expertise. Within the

sections that follow, a table at the end of each section will highlight the product / product

combinations that most Federal Agencies own and how they can facilitate the process or

project, program and performance management integration.

ii. Manage Requirements

Although the management of all IT system projects demands requirements management as the

most fundamental of all functions for the successful delivery of a new or augmented service, it

is often the most overlooked. As a result of internal politics, policy or interpretation of the FAR,


Federal agencies are often faced with the challenge of defining needs whilst having to remain at

arm’s length from the very people from which they need to collect the requirements. This

fundamental challenge often results in the development of requirements that are fragmented

or incomplete, or a set of requirements without the context of the customer or business need.

This can be exacerbated by the requirement to fit a system purchase within a pre-determined

budgetary cycle. Commencing your processes based on identified business need in April for

example, will mean you have a very short period of time into which you can squeeze all of the

steps that due diligence requires, forcing the rushed interpretation or total disregard for actual

business and end user requirements. The result has been systems that at best are delivered in a

timely manner but suffer poor adoption and end user satisfaction rates, ultimately being

replaced or growing so considerably in scope that the time and money spent fixing the system

to what it should have been in the first place eclipses the original build cost.

The management of requirements begins during the ‘Architect’ stage of the performance

improvement lifecycle and prior to the start of the System Development Lifecycle, but is an

ongoing (oft overlooked) function with dependencies between the other functions of the

program. The management of requirements is comprised of the following activities:

1. Collect and Define – Collaborate with the customer(s) to identify and explicitly define

the technical requirements of the technical solution. Requirements should be fully

defined for the establishment of the program / technical solution scope. As the program

evolves and the technical solution is deployed to the customer(s), the ongoing collection

and definition of requirements needs to occur.

2. Analyze – Review the customer(s) requirements to identify similarities, redundancies, or

gaps between them. As new requirements are identified during either the development

of the technical solution or post-deployment, those requirements need to be analyzed

against existing documented requirements or already fulfilled requirements.

3. Update – Based on the results of the analysis, prioritization, or additional program

management functions, requirements may need to be consolidated, eliminated, or

enhanced.

4. Prioritize – During the ‘Architect’ stage of the performance improvement lifecycle,

requirements are prioritized to determine those that will be developed and

implemented in the technical solution for the customers. This prioritization can be

formalized in a manner that takes into account customer value, risk, or other factors.

After the requirements are prioritized, the set of requirements now forms the basis of the

scope. At this point the management of the requirements does not end, but rather it continues

throughout the lifecycle of the technical solution. For instance, as the solution is being


developed, the scope may shift or change. A change in scope could require that a particular

requirement not be met in the first iteration of the solution.

The gathering of requirements and proposal of solutions to defined business problems should

be driven by what we term a solution map. A solution map develops the real cost analysis for

the delivery of a given solution including all cost elements comprising hardware, software,

maintenance fees, services (consulting and technical) and ongoing costs. Inclusion of all of the

actual cost elements and visibility thereof in the authorization process of any proposed IT

project is vital if an informed, duly diligent judgment is to be made as to the most advantageous

manner in which to solve the business need or problem at hand. Whilst acknowledgement of

the internal expertise on hand to maintain and operate a proposed system should be weighed

in the process, personal preferences for a particular technical platform, vendor or solution

provider should not weigh into the decision making process.

Specific to the development of a solution map the following products provide functionality that

naturally supports the collection of the data to inform accurate pricing and for the development

of project timelines and milestones.

Product Integrated? Leveraged Capabilities

Microsoft SharePoint Yes Collaboration, Excel Services, Electronic Forms, Dash-boarding, Alert and Notification

Project Server Yes Project Plan Development, Milestone Definition Portfolio Server Yes Project Plan Integration, Resource and Dependency

Management Microsoft Office Yes E-mail, and Spreadsheet integration

Table 1: Requirements Management Products

A description of the use-case for the components listed above appears with a conceptual

architecture at the conclusion of this paper.

iii. Manage Scope

Scope Management is critical for programs. The program itself may be ever evolving, making it

that much more critical that the scope is managed on an ongoing basis in order to contain

costs, schedule, and ensure that the planned deliverables are realized. Scope creep (program or

product) is one of the primary reasons for federal IT projects languishing without delivering

results. To effectively contain scope, it is essential that requirements are detailed, customer

needs are managed, milestones and delivery dates are set and the developers have a clear

understanding of how the requirements are to be fulfilled by the technical solution.

Scope is initially developed during the ‘Invest’ stage of the Performance Improvement Lifecycle,

but is managed throughout the System Development Lifecycle and is impacted based on any of

the other program management functions. The agreed upon scope ultimately results in the


identified cost and schedule elements detailed in the project plan. Scope management, like

requirements management has similar activities that are performed and should be thoroughly

documented and managed before any solution is selected and proposed to the IT control

organization. Buying software is not the full cost of the solution, the hardware platform

required and the time and technical expertise that will be required from at-cost external

support must also be considered before a valid evaluation and selection can realistically deliver

a best value solution.

It is understood that during the development of the technical solution unforeseen

circumstances may arise that will necessitate modification decisions regarding scope to be

made. For example, if it is discovered that performance is not adequate (and is a primary

(highest priority) requirement of the overall solution), some of the development costs may

need to be re-allocated to upgrade physical hardware or underlying network infrastructure. In

this and many other similar cases, the scope or the program and product need to be actively

managed and adjusted accordingly with any resultant shifts in delivery timeframe or budget

being clearly understood, communicated and recorded.

Scope is what defines the cost and schedule that are required. To this end, it is imperative that

it is managed accordingly and communicated actively to ensure that any projects or programs

with dependencies upon the new systems can, in turn, understand any ramifications. A

consideration here must be what the consequences will be regarding decisions of how and

where to invest within the other components of the IT portfolio if disruptive scope changes

occur.

For example, consider the impact if an organization develops requirements, has the alternatives

analyzed, makes a selection, has a budget submitted and approved, and makes an award for an

organization to outsource their messaging platform in order to realize tangible cost savings on

owning and running physical infrastructure. If that award is protested by a disgruntled vendor,

essentially stopping anticipated savings from being realized, the entire IT budget and portfolio

of services will be seriously impacted and must be re-evaluated in light of the fact that the cost

of running the existing infrastructure will not go away as planned but, will instead, be ongoing

whilst the legal battle ensues. This change in reality must be updated and reflected in the

program level budgets and may well result in other previously approved IT projects being moth-

balled or outright cancelled, but regardless of how difficult this impact is, it must be visible and

must be managed.

The following Microsoft products provide functionality that naturally supports the management

of scope to ensure that the program / project are poised to successfully deliver an agreed upon

set of business requirements.






Table 2: Scope Management Products

iv. Manage Resources and Monitor Performance

As the technical solution is developed and implemented within the ‘Implement’ stage of the

Performance Improvement Lifecycle, resources and their performance need to be managed and

monitored to ensure they are delivering in line with the project delivery plan and milestones

that were laid out in the IT solution evaluation and selection stage. This methodology allows

significantly better assessment of actual delivery against a performance based contract.

It is understood that financial, equipment, human capital and other resources related to the

development and delivery of the solution can all be negatively impacted in a moment’s notice

for any number of reasons. What is important is that the resulting effect on the program are

thoroughly understood and accurately conveyed in a timely manner so that decisions on

program/project continuance, accommodation of change or derailing it altogether can be made

long before a program/project falls into a state in which it languishes and drags on without a

realistic chance of recovery or success

Understanding the implications an issue with resources or their performance may have on both

scope and requirements is imperative. It enables the program to adjust accordingly to ensure

the program is able to press forward in the face of adversity and that deliverable(s) continue to

be produced effectively and efficiently.

The project plan itself is a fundamental starting point for managing cost, schedule, and human

capital; however, a complete solution offers visibility into other aspects of the program as well,

such as additional project resources, the performance of all resources, and the dependencies

with other programs, projects and management functions.

A solution that enables the program manager visibility into all of the resources, their respective

performance, and the scope and requirements they each are related to, provides a holistic view

into the program. This view can assist with course correcting in much shorter time frames, thus

alleviating compounding risks to the program. The following Microsoft products provide

functionality that naturally supports the management and monitoring of cost, schedule,

resources, performance, and their dependencies.






Table 3: Resource and Performance Management Products

v. Manage User Feedback

Upon successfully delivering the technical solution to the customers, the program still has an

obligation to the customer and the program itself to collect user feedback. Feedback is critical

to ensure that the deliverable has met the requirements as they were defined by the customers

up front and to provide insight into potentially new requirements. In technology terms User

Acceptance Testing (UAT) can deliver an initial adjustment to the program pre-delivery but as

the real world of work is changed through the systems new and efficient functionality end users

will inevitably have modifications, additional functionalities and other comments that will prove

valuable in optimizing and improving the system. Furthermore changes in the legislative

mandates the system addresses may well also require accommodation.

User feedback is a key input into the requirements management function. Collecting the

feedback can be accomplished through various means, including, online surveys, formalized

meetings, etc. Once collected, an analysis of the feedback against the existing requirements,

scope, and functionality of the technical solution determine what action is necessary. For

example, in the event that the user indicates that the solution is slow, a review of the network

might be called for. In the event that the user feels that the solution is missing a piece of

functionality, a review of the requirements and scope may be called for.

Ultimately, the challenge is always the balance between the customers’ needs, the cost to meet

the needs (if in fact they are unmet), and the available resources. The program as a whole,

having just been moved into operations at this point, can be derailed due to negative feedback

from users.

For example, users may be reluctant to adopt the new solution. They may not have the skill set

to be able to leverage the technology without training. Having a good understanding of the

users and an understanding of how their original needs were met with the solution delivered,

empowers the program to mature its relationship with its customers. The following Microsoft

products provide functionality that naturally supports the collection, analysis and management

of user feedback.






Table 4: User Feedback Management Products

VII. A Conceptual Solution Architecture Within this whitepaper we have laid out the challenges and a real world proposed methodology

for unifying the four disparate processes through which acquisition and deployment of IT

solutions occurs within the Federal Government. What we will now add is a process/procedural

overlay that straddles and unifies the currently stove-piped process work streams and offers a

conceptual technical architecture that can enable management of the process and visibility into

the results.

i. Overlay Process

Immediate re-alignment and coordination of Program Management, Acquisition, Budget,

Governance and IT Management is not realistically going to happen magically overnight. The

only way to accomplish realistic short term and incremental long term gains is through a

process of procedural accommodation and loose system interconnection.

If we take the steps of the acquisition process as laid out in the table below we can align the

tools available and the method in which they are employed to demonstrate a coherent, quickly

deployable approach.

Process Step Tools Utilization Method Identification of a business need.

SharePoint InfoPath Form Services

Business Units submit requirements for functionality or support and suggested solutions to the IT organization utilizing browser agnostic web based forms that are received into an e-mail enabled SharePoint list that is managed and monitored by the IT team and the IT Investment Review board.

Research into and evaluation of alternative technical solutions.

SharePoint Project Collaboration Site

Project Server

Information pertaining to proposed solutions is collected into review sites in SharePoint where it is centrally discussed and assessed. Project plans detailing the typical estimated deployment timeline and support requirement for each proposed solution are developed by vendors in a standardized Microsoft Project Template and submitted as part of the review process.

Selection of a proposed solution.

SharePoint Collaboration Site and Surveys

The IT review board (or other such assessment authority), reviews the proposed solutions and accompanying documentation in advance of the decision making meeting or meeting date, post questions and discussion points and review the existing IT portfolio to check for any existing solutions


Process Step Tools Utilization Method within the portfolio that could address the defined need. The final decision to move forward with an investment can be made in person, or using SharePoint approval workflows to enable decisions to be made without the need to wait for an arbitrary meeting date.

Application for authority to procure (through IT selection boards or through the use of discretionary funding).

SharePoint InfoPath Form Services

Project Server

Upon selection/approval the InfoPath form submitted as the initial request is advanced into the initial procurement process with the data elements such as the name of the software, the milestones in the deployment timeline et cetera, being provided in a simple form for review and utilization by the procuring authority. If acquisition is amenable and the procurement system accepts data imports, the form data can be posted directly into the system removing data entry inconsistencies. Having an industry best-practice project plan for the deployment of the solution including major milestones and project phases calculated in business day increments allows for much more effective firm fixed price and performance based contract development.

Issuance of a solicitation.

SharePoint

Agency Procurement System

Draft solicitations and the process of reviewing and approving them before they are issued, and the receipt and analysis of bids can all be improved through the use of SharePoint Collaboration Sites.

Evaluation of bids and source selection.

SharePoint Collaboration Site

The sites can be used by those preparing and vetting the RFP pre-release but can also be used as a centralized repository of responses that the evaluation committee can review, discuss and decide upon.

Project commencement / deployment.

Project Server

Project Portfolio Server

SharePoint Collaboration, Dash-boarding and Analytics

Upon approval and selection of a bidders submission the project plan developed in the cost and level of effort modeling can now move into the portfolio of ongoing projects and be managed and monitored as such. Achievement of major milestones and project gateways can be monitored by an assigned program manager and, as it is stored as data centrally, can be reviewed at any time within the context of the overall IT portfolio. Centralization of the management process also enables the transition smoothly of program management responsibility between individual program managers to guard against “going native”. Furthermore the management of IT Program Manager assignment cycling can be managed as a timed workflow in SharePoint, thus regulating the change-over activity.

Steady state operations.

SharePoint Surveys SharePoint surveys can allow the collection of feedback and end user commentary on the new system either through the use of surveys, the collection of e-mails requests and criticism can be used to assist in the ongoing improvement of the system in all elements.

Migrations/upgrades (potentially)

Project Server and SharePoint

Project Planning and the thorough collaboration with all dependent system components

Ultimately decommissioning and retirement.


ii. Technical Architecture

The three principal technical components mentioned throughout this paper, namely Microsoft

SharePoint Server (2010), Microsoft Project, Microsoft Project and Portfolio Server and the

underpinnings (Active Directory, Exchange (or another e-mail platform) and Microsoft Office),

are already within the IT Portfolio by most Federal Agencies and in the spirit of the Federal

CTO’s 25 point plan leveraging what you already own, either on premise, or in a cloud

configuration to help solve the challenges of budget and transparency is a paramount. The

components listed require little (or no), integration effort as they are built on a common

development platform and as such handling and merging data between project plans, across a

portfolio of investments, managing resources and managing budgets can all occur in the tools

familiar to the end user community. In addition, the use of Microsoft SharePoint as an

underlying platform enables support of the IT Program Manager Development track by

providing a unifying centralized resource point for the training materials in video, text,

PowerPoint, PDF, and image format. Management of the training track and individualized views

of progress through a pre-determined set of curricula are all well proven functionalities of

SharePoint and as a result the single platform delivers high value through provision of multiple

functional benefits in a truly cross browser, end-point agnostic manner.

VIII. Embracing the Challenge As described above, the challenges faced by Federal agencies today are not new. They are

complex and multi-dimensional. Measuring performance, mitigating risk, and achieving

incremental successes are not only necessary for the technology programs themselves, but also

for the development of the program management function at each agency.

A foundational platform to support program management, regardless of the approach taken to

implement the function at an agency is critical. There are such tight dependencies between

requirements, scope, resources, and the customer that it is necessary to manage the

dependencies explicitly. Manually trying to manage requirements, scope, resources, and the

customer ultimately results in something slipping through the cracks. A solution is needed that

is designed to support program management and the dependencies between each function

that provides a foundation through which the functions of program management can be

matured collectively.

As our nation is faced with extremely tight fiscal constraints, it is our duty to embrace this

challenge to ensure that the money being spent on IT is being spent effectively, efficiently, and

is delivering results. The change will not happen overnight, but establishing a solid foundation

to drive maturation and integration will undoubtedly benefit the delivery of technology in the

federal government for years to come.


IX. Conclusion Addressing the challenges posed to all of us by Vivek’s 25 is going take a significant change in

how we work together as IT professionals, Acquisition Specialists, Budget and Compliance

Experts and Project management professionals. This challenge should not be used as an excuse

to buy even more, large standalone systems, pay a great deal for their integration and try to

reform and unify our processes, that approach is indicative of what got IT program

management in this mess to begin with. The tools to facilitate the change are already within the

IT portfolios of most US Federal Agencies, are familiar and often used by existing staff across

the different affected disciplines and can be enacted in a tightly, or loosely integrated fashion

depending on the individual cultural preferences of the agencies involved. The key to success is

simply the normalization of the data points to be monitored across the five

domains/organizations and due diligence in keeping that data up to date. As a follow-up to this

white paper, Planet Technologies will be releasing form templates, common sample data

elements and definitions, and project templates that Government Agencies can download and

tailor to assist in getting the process started.

Meeting the Challenge of Vivek Kundra's 25 Point Plan

Technology

management processes

critical processes

governance processes

work processes

dependent processes

processes inherent

business management

problem spacethe problem