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