Meeting the Challenge of Vivek Kundra's 25 Point Plan

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.

Planet Technologies 1|Page

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


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.
Program Management

Manage Requirements

Manage Scope

Manage Resources and Monitor Performance

Manage User Feedback

Architect Invest Implement Operate
Improvement Lifecycle
Performance

Select
Preselect Select Implement Operate Decommission
Segment to
Authorization Authorization Authorization Authorization Authorization
Architect

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


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.

Planet Technologies 10 | P a g e

Management
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.


Management
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.


Management
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  SharePoint InfoPath Business Units submit requirements for functionality or
business need. Form Services 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  SharePoint Project Information pertaining to proposed solutions is collected into
evaluation of Collaboration Site review sites in SharePoint where it is centrally discussed and
alternative technical  Project Server assessed. Project plans detailing the typical estimated
solutions. 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  SharePoint The IT review board (or other such assessment authority),
proposed solution. Collaboration Site reviews the proposed solutions and accompanying
and Surveys 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  SharePoint InfoPath Upon selection/approval the InfoPath form submitted as the
authority to procure Form Services initial request is advanced into the initial procurement process
(through IT selection  Project Server with the data elements such as the name of the software, the
boards or through milestones in the deployment timeline et cetera, being
the use of provided in a simple form for review and utilization by the
discretionary procuring authority. If acquisition is amenable and the
funding). 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  SharePoint Draft solicitations and the process of reviewing and approving
solicitation.  Agency them before they are issued, and the receipt and analysis of
Procurement bids can all be improved through the use of SharePoint
System Collaboration Sites.
Evaluation of bids  SharePoint The sites can be used by those preparing and vetting the RFP
and source selection. Collaboration Site pre-release but can also be used as a centralized repository of
responses that the evaluation committee can review, discuss
and decide upon.
Project  Project Server Upon approval and selection of a bidders submission the
commencement /  Project Portfolio project plan developed in the cost and level of effort modeling
deployment. Server can now move into the portfolio of ongoing projects and be
 SharePoint managed and monitored as such. Achievement of major
Collaboration, Dash- milestones and project gateways can be monitored by an
boarding and assigned program manager and, as it is stored as data
Analytics 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  SharePoint Surveys SharePoint surveys can allow the collection of feedback and
operations. 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  Project Server and Project Planning and the thorough collaboration with all
(potentially) SharePoint 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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (6)

Semelhante a Meeting the Challenge of Vivek Kundra's 25 Point Plan

Semelhante a Meeting the Challenge of Vivek Kundra's 25 Point Plan (20)

Último

Último (20)

Meeting the Challenge of Vivek Kundra's 25 Point Plan