Appendix A: Project Management Methodology (PMM)

BearingPoint’s Project Management Methodology (PMM) is a basic, disciplined, and

structured approach to managing projects. The purpose of this methodology is to
make the defining, planning and controlling of projects a repeatable, consistent, and
successful process.
PMM is intended for use on any type of project, regardless of size or duration,
underlying technology, application area, team composition, or client type. The project
manager has the flexibility to adapt those aspects of the methodology that best suit the
particular project and help ensure the achievement of objectives and realisation of
project benefits.
This methodology is intended to minimise risks and uncertainties by:
◼ Defining standard processes and techniques that can be applied to all types of
projects
◼ Following a consistent, structured approach
◼ Establishing effective management controls and procedures
◼ Facilitating client involvement

Managing Project Staff

Managing Organizational Change

Project
Project Project
Project Plan Management
Definition Close
and Control

Quality Management
Risk Management
Change Control and Issue Management
Configuration Management

Project Management Phases

The PMM model comprises four major phases as illustrated above. Each of these
phases is described in detail in the full methodology documentation but a brief
synopsis of each phase is provided below:
◼ Project Definition
The Project Definition Phase analyses and confirms the work required to accomplish a
project by defining and agreeing the objectives, scope, benefits and risks. These are
documented in the Management Plan and Risk Register.
◼ Project Plan
The Project Plan Phase defines, in detail, how specific project phases will be
conducted. It covers the project approach, the tasks that need to be accomplished, the
time frame in which they will be performed, and the team members who will perform
them.
◼ Project Management and Control
The Project Management and Control Phase manages the daily activities of the project
against the schedule defined in the Project Plan phase. This is achieved through both

1
iterative processes (e.g., weekly status reporting) and continuous processes that
require attention in a non-scheduled manner (e.g. risk management).
◼ Project Close
The Project Close Phase covers three main areas: delivery of the project deliverables
to the client, closing the project, and conducting post-implementation reviews.

Approach to Quality Management

Managing quality is critical throughout all phases of the development lifecycle.
Quality in a Systems Integration project is achieved when all deliverables are
produced:
◼ according to contract, specifications and standards
◼ to users’ needs and expectations
◼ on time and within budget
Achieving a balance between these variables is difficult but critical to project success.
The project manager's role is to optimise the project's quality, cost factors, and
schedule. Successful quality management is achieved when all deliverables:
◼ are subject to adequate reviews
◼ meet requirements
◼ comply with standards
◼ require minimal amendment following testing
Within BearingPoint’s approach to quality management, there are three key steps to
ensure quality objectives are met:
◼ Plan for Quality
◼ Use of Quality Assurance Framework
◼ Perform Quality Control Activities

Plan for Quality

Quality is not a random project outcome; its achievement must be planned. The
objective of this step is to ensure that all the standards and guidelines required to plan,
manage, staff, control and deliver the project effectively have been identified.

Use of Quality Assurance Framework

Quality assurance is the definition and execution of measures to ensure all
deliverables are to standard and fit for their purpose. It involves:
◼ Ensuring the project methodologies, standards, and guidelines are appropriate and
reasonable for the project environment
◼ Ensuring that the specific standards and measures identified in detailed work plans
are appropriate and reasonable for achieving the defined quality objectives for
specific deliverables
◼ Reviewing the adequacy of and adherence to general project controls, such as
lifecycle methodologies and change control procedures
◼ Ensuring quality control activities are performed consistently and continuously
◼ Analysing errors and defects to provide a basis for improving the quality of project
deliverables
In addition, the project manager must assume responsibility for reviewing all
significant quality findings and recommendations and acting upon the suggested
actions in a timely manner. The project manager must ensure that the detailed work
plans are updated to reflect implemented quality recommendations.

2
Perform Quality Control Activities
The purpose of quality control is to identify defects and have them corrected. Quality
control is the responsibility of each project team member. It must occur throughout
the project, and not just when a deliverable is complete.
Two methods generally used to monitor and control quality are:
Reviews
◼ Design Reviews are used to evaluate the content and correctness of the
deliverables, ensure consistency among project components; and, verify
deliverables conform to specified standards and guidelines. The following are
examples of types of reviews:
◼ Self-Review-The person producing the deliverable compares attributes of the
deliverable against predefined criteria or checklist
◼ Informal Review - Peers review manageable units of work in brief review
sessions; peers offer insights based on their own work assignments and
experience. Common during program development and testing.
◼ Formal Team Review - Project team members familiar with the overall system
review major task deliverables. Appropriate when: interaction is required to co-
ordinate work. The deliverable produced becomes the foundation for future work;
and/or consistency of subsystems and interfaces is affected.
◼ Structured Walkthroughs for reviewing major project deliverables. This often
precedes formal user acceptance review, also useful when: subject material is
critical; diverse participation is necessary to verify accuracy and completeness,
participants are from diverse parts of the organisation.

Implement Corrective Action

Defects and/or non-conformities arising from a quality control checkpoint must be
corrected. To correct the problem, the root cause of the defect or non-conformity
should be determined.

Managing Risk
Project risks are uncertainties, liabilities or vulnerabilities that may cause the project
to deviate from the defined plan. Every IT project carries some element of risk; it is
probable that progress will deviate from the plan at some point in the project lifecycle.
The objective of a risk management process is to minimise the impact of unplanned
incidents on the project by identifying and addressing potential risks before significant
negative consequences occur.
Risk management incorporates the identification, analysis and management of project
risk. After potential risks are identified, the purpose of risk analysis is to determine
the relative exposure in terms of time and cost. Risk management is therefore
concerned not only with identifying risks, but also with reducing risks to an
acceptable level.
Potential project-level risks should be identified during the Project Planning phase.
An ongoing risk management process should then be carried out formally as part of
the Project Planning process, and thereafter monitored and updated as appropriate.
An effective risk management plan:
◼ Is proactive, focusing on prevention rather than cure
◼ Includes periodic risk assessments throughout the project lifecycle

3
◼ Incorporates a continuous process of risk identification, analysis, management and
review.
Risk Management Process
The project manager is responsible for identifying and managing risks to enhance the
probability of a successful project implementation. The risk management process
focuses on the proactive elements of risk management by introducing early risk
identification mechanisms and risk impact analysis methods. Using this, the project
manager will be better positioned to identify and manage risks, rather than allowing
them to become major problems or result in actual project delays.
Risks change during the course of a project. New risks may be identified, as more
information becomes available, existing risks may be eliminated as a result of internal
or external influences. Therefore, risk management is an ongoing project
management function. As each project phase is initiated, the project manager and
team leaders should review the risk management plan and discuss specific risks
associated with the phase.

Manage Risks
The following diagram demonstrates the steps within a risk review process. A
detailed work plan will not be approved until the risk review process has been
completed. The Director of Systems Integration must approve the risk review
process.

IDENTIFICATION ANALYSIS MANAGEMENT MONITORING

Identify initial
project-level risks

Document specific
risks

Perform risk
impact analysis

Develop and
implement risk
management plans

Monitor and update

the risk profile

Risk Review Process

Approach to Change Control

All projects are subject to change throughout the project life cycle. Neither changes
nor issues can be eliminated, as both are normal project occurrences. Structured and
comprehensive procedures for managing both changes and issues reduce project risks
and are therefore essential components of any project. Any changes to a signed-off or
baseline deliverable must go through the structured change control process.
Within the context of PMM, the following definitions have been developed:

4
◼ A Change is any activity that alters the scope, deliverable, architecture, cost or
schedule of a project.
◼ An Issue is a situation, action, problem or question arising during the performance
of the project which demands action to resolve it over and above the tasks
identified in the plan. Left unresolved, an issue will impede or prohibit project-
related progress or development by delaying or suspending work effort.
The primary objective of change control and issue resolution is to establish a standard
method to document, analyse, approve, and communicate changes and issue
resolutions.

Effective change control and issue resolution involves the following responsibilities:
◼ Provision of a centralised change request monitoring and communication service.
◼ Co-ordination of all change requests and issue forms to ensure completeness and
consistency and to reduce duplication of effort
◼ Maintenance of current status information for change requests/issues in the review
and approval process
◼ Processing of change requests/issues by referrals to appropriate project
participants for analysis and input
◼ Compilation of summary statistics and reports to reflect the status of all change
requests
◼ Updating of project plans, based on information received from team leaders to
reflect changes directly related to approved change requests
◼ Monitoring the impact of approved change requests on the overall project
◼ Prepare reports to appropriate management personnel and the project steering
committee for review
The change control process is illustrated on the following page:

5
 Cosmetic Mandatory
Request Query
Change Change RESPONSIBILITY

1. Log the Change Initiator

2. Input to CCF System Test Manager

3. Assign for Analysis Project Manager

4. Identify Options (if appropriate) Team Member

Client/Initiator/
5. Decide on Action (if appropriate)
Project Manager

6. Update Plans & Budget (if appropriate) Project Manager

7. Complete Change Project Manager

8. Test Change & Update CCF System Test Manager

The change control process

Issue Management, Reporting & Feedback

To assist in the tracking and management of all change requests/issues raised during
the project lifecycle, BearingPoint have developed their own issue recording and
tracking system. This tool is a web-based QA System that manages all change
requests/issues raised throughout the project lifecycle. The system allows authorised
users to track all modifications to an application prior to release to the client. This
system is available online to the project managers, development team and system test
team both in BearingPoint and from the client site via a secure connection. The
system can also be enabled for client use to assist in the management of the user
acceptance testing process.
As change requests/issues are raised, the details are recorded on the system by the
project team. Screen shots and any other related documentation can effortlessly be
attached to the record as they arise. Each change/issue is then assigned to a member of
the project team pending resolution. Team members can view a list of change
requests/issues assigned to them at any time. Project managers can use the system to
review progress, access detail on open issues, assign issues to individuals and to
generate code releases. The system records the status of each change request/issue
raised and tracks the workflow between members of the project team. The system can
also be used over multiple projects.

6
A wide range of statistical and summary reports are available which benefit both the
BearingPoint project team and the client in ensuring that all change requests are
managed in a controlled environment and issues raised are being resolved effectively.
The reports available include the following:
◼ Detailed reports on specific types of change requests/issues raised i.e. (Open,
Closed, Deferred, In Test, Pending fix etc)
◼ Report on the time taken to re-test
◼ Report on time taken to resolve
◼ Report detailing all issues that have re-occurred
◼ Summary reports by status, area, grade
An archive facility is also available to enable project records (and the issues
associated with them) to be archived when no longer in use. These records can
however be re-imported at a later date if required.

Configuration management
Controlling project deliverables is a crucial element of project management. Current
information technology projects are often performed by a diverse project team,
working in a distributed environment. Therefore, maintaining control over key project
deliverables is a challenging process. Configuration management is the collective
term used for the control of tangible project property—primarily project
deliverables—throughout the project lifecycle. Configuration management
encompasses a major project management area previously referred to as version
control, but includes additional areas of control over all project property.

Configuration management includes controls needed to:

◼ Ensure that project property (software and documents) is physically secure at all
times;
◼ Protect the integrity of completed deliverables;
◼ Ensure that work in progress is secure and backed up on a regular basis;
◼ Control updates made to completed deliverables;
◼ Ensure that the appropriate version of a deliverable is used;
◼ Control the release and issuance of updated deliverables; and,
◼ Ensure that related deliverables are kept in step.

Configuration management processes and procedures are required for all projects.
System integration and implementation projects have more complicated configuration
control requirements, but all projects require that documentation, procedures and files
be controlled. Configurable project property may include a wide variety of items, such
as source code modules, test data, directory structures for LANs (local area networks)
and personal computers, installation procedures, word processing/ spreadsheet files,
training materials, and data files.
Ongoing configuration management processes should use an automated configuration
management tool to reduce the labour intensity of manual control, and to produce
required control reports.