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