Meeting The Mission
It’s why you’re here
Align
the Project Mission with the Agency’s
Mission What is your
agency’s mission? What is the relationship
of your project to your agency’s
mission? Project activities need
to support this mission.
Know
the Project Stakeholders
A strong project mission can not
be created in a vacuum. Who are
the people with an interest in the
outcome of the project? What are
their common expectations? Stakeholders’
expectations are rarely spelled
out in legislation, executive orders,
or formal memoranda.
Amplify the Voices of
Your Customers
Who will be paying for this project?
Who will actually be using the systems
and processes being designed? Clarify
the business priorities of these
customers and their criteria for
success. Actively and emphatically
communicate this information. Do
this for customers inside the organization
as well as those outside the organization.
Maintain
High-Level Communication About the
Project Mission
Communicate steadily with stakeholders
and customers throughout the project.
This will help to manage their expectations
and requirements over time. Design
project development so that requirements
and expectations can be reconfirmed
at regular junctures. Periodically
check to see that stakeholders and
customers understand and support
changes, delays, and new developments.
Strategies
What do you want to accomplish?
Set Realistic Business
Objectives
What are the common business needs
of the organizations that will depend
on the system? What accomplishments
will be critical for the project
to be considered successful? Define
project boundaries at the outset,
and use this definition to manage
requirements throughout the project.
A clear definition of business success
will also help ensure that project
efforts support the agency’s strategic
plan.
Define a Sound Architecture
Drive Toward an Enterprise-Wide
Business Model
Ensure that the business model
meets business objectives while
remaining within the project’s scope.
Publish a detailed concept of operations
which distinguishes clearly among
the business model, the layout and
relationship of systems and communications,
and the technical architecture.
These should be anchored in an enterprise-wide
IT strategy.
Implement Systems Incrementally
Work toward a systems implementation
that will deliver, in twelve months
or less, incremental, useable levels
of functionality which support specific
business objectives. The detailed
concept of operations should explain
how the architecture will satisfy
these objectives and how it will
prioritize them. It should also
communicate responsibilities for
implementing and managing the architecture.
Coordinate Technical Standards
Which standards are essential to
ensure that the technical architecture
ultimately supports business objectives?
Define these, paying particularly
close attention to technical interfaces.
Develop a plan to ensure compliance
with architecture standards. The
technical architecture must be documented
to ensure its consistency with the
overall agency-level design.
Gain
Agreement on the Project Plan
The project plan formally captures
and documents agreements among customers,
stakeholders and project participants.
Secure an informed agreement up
front, and maintain this agreement
throughout the project life. This
will ensure that the project meets
expected results. This will also
help align the project with the
organization’s business plans and
supporting IT plans. Over time,
manage the project scope carefully,
since there will be a tendency for
different areas of the project to
acquire their own divergent momentum.
People
Understand the project participants
Organizational Leadership
Listen to the Customer and
Create a Vision
The project sponsor manages high-level
customer relationships, translating
key customer expectations into a
practical vision for the project.
To be effective, this vision must
be broadly communicated.
Commit to the Project
The most frequent cause of project
failure is the lack of involvement
of the organizational leaders. Ongoing
involvement is crucial. It is critical
to structure the project in such
a way that go/no-go decisions may
be made at highly visible milestones.
Leadership commitment stabilizes
the project so that it can accommodate
changes over time.
Leverage the Existing Organizational
Structure
The roles and responsibilities
of the project and its partners
are most effective when they correspond
with the way in which the overall
agency is managed. For example,
in an organization in which field
offices have a great deal of autonomy,
a centralized approach to IT management
could bring about unnecessary conflict.
Empower the CIO
The Chief Information Officer (CIO)
position requires extraordinary
qualifications in both IT management
skills and general management skills.
The CIO needs authority and visibility
to guide the organization in key
decisions. The CIO focuses on three
things:
Synergy. Bring realistic
synergy to IT strategy by focusing
disparate IT activities on their
contribution to the organization’s
mission. Ensure that business
objectives take precedence over
technological advances. Direct
architectural compliance across
the enterprise. Create a formal
strategic IT plan that reflects
business priorities.
Sharing. Leverage the
centralized technical authority
to reduce redundancy across different
organizational units. Enable them
to share systems and data, as
well as IT training, approaches,
and other commonly needed resources.
Coordinate a coherent strategy
for commercial off-the-shelf software.
Seek to make the enterprise technologically
seamless.
Support. Establish complementary
managerial and technical structures
to provide support for critical
enterprise functions. Do this
in a way that provides different
organizational units with the
flexibility they require.
Project
Leadership
Select a Strong
Project Manager
Empower a central point of responsibility
for project decisions, and clearly
distinguish this role from functional
program management roles. Clarify
the risks which the project manager
is expected to manage strategically.
"Leadership ability" is difficult
to articulate, and even more difficult
to find. At a minimum, it includes
the following characteristics:
Drive. Does the project
manager have a strong desire to
succeed?
Ability to Build Consensus.
Can the project manager get
key individuals to work together
towards common ends?
Ability to Take Risks.
Can the project manager recognize
opportunities and find ways to
seize them?
Ability to Communicate. Is
the project manager able to communicate
clearly and convincingly to all
parties?
Experience. Does the
project manager have a track record
of success? Look for characteristics
and experiences that relate directly
to the project at hand.
Technical Knowledge.
Does the project manager possess
demonstrated knowledge in the
appropriate technical fields?
Sense of the Big Picture.
Does the project manager
understand the project from a
broad business perspective?
Enable a Cooperative Environment
Nurture cooperation among members
of the leadership, including the
project sponsor, functional program
manager, project manager, contracting
officer and contractor. Create a
learning environment which attracts
individual skills to the table.
Actively encourage team members
to innovate by rewarding judicious
risk-taking.
Ensure Accountability
The project manager is responsible
for results. Successful project
managers actively encourage team
members to make minor challenges
known before they become major problems.
The project needs a "truth culture"
– let the messenger live. Stress
the importance of accountability
by systematically introducing constructive
criticism into current practices.
One recommended technique is to
outsource for independent validation
and verification (IV&V) support.
It is critical for the executive
leadership to listen to IV&V
advice. Another technique is to
create an anonymous channel for
reporting problems.
Project
Team Members
Get What’s Needed
to Succeed
What are the competencies of the
team? How does the staffing plan
distribute these competencies against
project tasks? Assess the team’s
particular strengths, then get the
additional expertise needed. There
may be a need to outsource for additional
skills to round out the team. Balance
the mix of management and technical
expertise, and the mix of contractor
and government personnel. Distinguish
between critical strategic activities
and tactical activities. Make use
of consultants to leverage the team’s
capabilities.
Keep the Core Team Together
Maintain a commitment to the integrity
of the core team. The project should
include the project manager, the
functional program manager, the
contracting officer and other key
players from project conceptualization
through implementation. Empower
a central point of responsibility
for technical decisions, including
standards and architecture.
Monitor Team Productivity
How does the level of effort contribute
to project deliverables and results?
How is the team progressing against
the project plan? Perform periodic
cost-benefit analyses and life cycle
cost estimates. This information
will be needed for go/no-go decisions
at major project and contract milestones.
Develop Competencies Over Time
Invest in building competencies
in key people. Institute and follow
a formal plan for skills training
and career development. Align the
competencies of team members with
the long-term needs of the project.
Processes
Making it happen
Planning
Define Success Up Front
Define project success in terms
of specific business objectives.
From the customer’s point of view,
how should different business objectives
be prioritized?
Use Metrics to Focus On Outcomes
Focus on outcomes rather than outputs.
Prioritize the metrics for which
project participants will be held
responsible. Gain agreement on critical
metrics and use them to drive planning
and delivery.
Integrate Planning Activities
Across the Project
Formalize planning processes. Assign
roles and responsibilities specifically
for planning-related activities.
The CIO can help anchor project
plans in the organization’s business
and IT plans.
Realign Plans Over Time
How will plans need to be modified
along the way? Make sure project
plans continue to support intended
business priorities. If the project
encounters significant changes,
then the original plans will have
to be realigned to ensure desired
results.
Managing
Technology
Choose an Appropriate
Development Model
Base selection of a development
model on careful consideration of
four factors:
Costs. Consider various
development alternatives and estimate
how they might contribute to project
costs.
Risks. Consider how much
risk the project faces due to:
- High visibility due to public
or political attention or requirements
- Highly compressed development
time
- High uncertainty associated
with the system’s requirements,
the technology that the system
will employ, or the way that
the system will affect business
processes
Complexity. Consider
the project to be complex if it:
- Affects many organizations
or functional areas.
- Results from business process
reengineering, dramatically
altering the use of information
technology.
- Requires new or rapidly advancing
technology.
- Requires a long time for development.
Type. Consider the general
type of the project:
- A new development
- A modification of an existing
system
- A system integration
Select an Appropriate Life
Cycle
The life cycle provides an organizing
structure with which to align project
objectives with appropriate technologies
and resources. Different projects
require different degrees of rigidity
in the sequencing of their phases.
Long, complex projects intended
to modify familiar systems typically
yield to more rigid sequencing.
On the other hand, less rigid sequencing
may be required to achieve a series
of innovations under conditions
of high uncertainty.
Deal with Shifting Priorities
Business needs may change. All
requirements must be formally managed.
Address downstream changes in the
life cycle through systematic risk
assessment.
Make Progress Visible to All
Project participants need a clear
idea of how well the project plan
is working. Establish a set of key
progress indicators and make them
visible to all project participants.
Know The Limits of Automation
Don’t simply automate existing
processes. Rethink existing processes
instead of simply "paving the cowpaths."
If your agency lacks the skills,
use consultants to facilitate business
process reengineering (BPR) and
information modeling prior to defining
requirements.
Leverage Expertise in Established
Management Areas
Managing Inputs. Encourage
project participants to address
evolving technical priorities
with appropriate resources. For
example, employ contract incentives
to deliver the desired results
in accordance with the projected
cost and schedule. Offer high
incentives (18 - 20%) to in-house
staff.
Managing Activities.
Use scope management techniques
such as a Work Breakdown Structure
(WBS) to organize project activities
and tasks. Graphically display
the work to be accomplished. Update
the display periodically to reflect
reality.
Managing Outcomes. Encourage
all staff to identify potentially
problematic outcomes. Use formal
risk management techniques to
anticipate and mitigate project
risks.
Controlling
Tasks
Put Meaning in the Metrics
Define requirements so that they
may be thoroughly tested and validated
at the unit and systems level of
granularity. Identify frequent milestones
with a defined set of measurable
pass/fail performance criteria.
Structure related contracts so that
they reflect the same units, granularity,
and milestones. This enables you
to measure earned value throughout
the contract life. These criteria
should comply with a pre-established
test plan.
Leverage Expertise in Control
Areas
Controlling Inputs.
Conduct life-cycle cost analysis
to evaluate the impact of design
implementation alternatives throughout
the project. Use agreed upon plans
to control the resources applied
to the project. For example, periodically
review actual project expenditures
and compare them to the projected
budget.
Controlling Activities. Standardize
processes which deal with the
most routine activities. For example,
routine progress reports can be
structured to capture and highlight
exceptions from anticipated progress.
Controlling Outcomes.
Use configuration management processes
to ensure the project is building
what the customer wants. The implications
of changes along the way can be
understood and incorporated while
driving toward the desired result.
|
One
reviewed project was situated within
an agency which had recently undergone
major budget reductions and large-scale
structural changes. Because senior
management was unclear about customer
expectations, the agency had been
unable to articulate a clear strategic
view of the project and its role
in the new environment. Customers
had insufficient information to
guide them in improving work processes.
The commission recommended that
the agency work with customers to
accelerate development of a new
strategic plan, and that it publish
a concept of operations to communicate
how the system would operate in
future years.
One
reviewed project reversed its declining
fortunes by making substantial revisions
to project requirements several
years into the project. Project
leaders had conducted an evaluation
of requirements, leading to large
but necessary reductions in both
scope and requirements. Though initially
disorienting, this reduction did
much to stabilize the project, leading
to a significantly improved outlook
for project success.
The
Commission encountered a project which,
after eight years of planning, had
yet to define an architecture. The
project had come to rely heavily
upon the functional program knowledge
of the technical contractor, and
there were insufficient technical
resources involved in crucial technology
decision-making. The Commission recommended
that the organization establish
technical requirements for deliverables,
define modular delivery of specified
interim products, monitor product
delivery, and generally strengthen
the role of contract management.
The
architecture should provide a focal
point for project definition and
clarity. Indeed, ambiguity surrounding
this fundamental concept may be
a clue that your architecture requires
attention. One Commission-reviewed project
exhibited a number of inconsistencies
in its use of the term "architecture."
This led to conflicting expectations
when information about the architecture
was disseminated among project participants.
Upon closer inspection, the Commission
found that the architecture required
broad realignment with the organization’s
strategic plan and budget.
One
Commission-reviewed project had negligible
high-level involvement on the part
of its organizational leadership.
It turned out that no single individual
was accountable for providing such
leadership. Among other things,
this explained the absence of a
formal planning process and clear
business objectives.
The
Commission encountered one project which
had clearly identified the information
needs of key stakeholders, but was
having great difficulty prioritizing
these needs. The centralized organization
running the project simply did not
have the resources or the authority
to provide an enterprise-wide solution
to all of its widely distributed
lines of business. Among other recommendations,
the Commission noted the need to establish
an agency-level CIO who could focus
the project architecture on the
most critical common needs of the
different lines of business.
The
Clinger-Cohen Act identifies four
core competency areas for CIO’s:
1.
Federal Information Resources Management
· Policy and Organizational Knowledge
· Information Resources Strategy
and Planning
· IT Acquisition
2. Capital Planning
· IT Performance Assessment
· Capital Planning and Investment
Assessment
3. Change Management
4. Managerial/Technical
· Professional Development and Training
· IT Topics
· IT Trends
Project
leadership does not simply appear;
it must be nurtured. Among all of
the projects reviewed by the Commission,
those with the greatest chance for
success were those which sought
to grow and develop leadership competencies
over the long run. Though many aspects
of project management may be reduced
to defined processes, the development
of project management leadership
competencies remains a difficult
but worthwhile challenge.
One
Commission-reviewed project exhibited
no partnership among functional
program leaders, IT managers and
contract managers. Significant confusion
resulted among both contractor and
agency employees as to who made
key decisions. In the absence of
cooperative leadership, critical
analysis of functional requirements
was seriously lacking. The Commission
recommended that the project not
only clarify the respective roles
of project team members, but that
it reorganize its executive steering
committee to make it truly accountable
for all final project decisions.
In the majority of reviews it has
conducted, the Commission has recommended
that organizations immediately establish
a process for independent validation
and verification and that executives
explicitly consider IV&V recommendations
when making decisions.
One
Commission-reviewed project found a significant
shortage of staff on the agency
management team. The Commission recommended
that the management team take all
possible actions to expand its staff,
concentrating on the addition of
technical expertise in computer
software and systems. The Commission also
recommended that contract personnel
be more effectively used to provide
project management support
One
Commission-reviewed project revealed a
clear need to integrate IT planning
across various organizational units
involved in the project. A new business
concept of operations required that
IT processes be realigned to meet
evolving demands. The Commission recommended
that the organization use experts
in BPR and information modeling
to facilitate the necessary process
analysis and redesign
One
agency requested the Commission review
its enterprise-wide architecture.
The agency appeared to lack a structured
process for testing products within
the architecture before placing
them into use. The Commission recommended
a centralized test bed which would
enable the agency to simulate new
functionalities and assess them
before placing them into service.
One
Commission-reviewed project faced serious
risk of failure due to recent major
shifts in the agency’s mission.
If carried out according to the
original plan, the project would
simply have automated certain processes
which no longer made sense in the
new environment. The Commission recommended
that the organization cease development
of certain sub-systems, and retain
consultants to facilitate high-level
process redesign.
The
Commission reviewed one project which
had recently negotiated movement
from a cost reimbursement contract
to a fixed price contract. While
the Commission concluded that this was
an appropriate step, it noted that
the agency would need to consider
more thoroughly the different risks
entailed by the new contract incentives,
and that it would need to balance
the risk between the agency and
the contractor. For example, the
Commission recommended that the agency
tie progress payments to accomplishment
of specific milestones.
One
recently redesigned project lacked
test and acceptance procedures for
a large set of new technical requirements.
The Commission recommended that the agency
establish test and acceptance procedures
at frequent milestones consistent
with the project’s work breakdown
structure. It further recommended
that the requirements be re-baselined,
and frozen, in order to ensure an
acceptable level of functionality.
The
Commission reviewed a project whose software
development process was in a perpetual
state of change. The Commission recommended
the establishment of configuration
management baselines as well as
cost and schedule baselines.
|