Appendix A: PQA Introduction to Participants Example

Place L-9999 XXXXXX

01–02 June, 2013

Start 900

Finish 1800

PARTICIPANTS

Peter, XX IT manager

Paul, XX Trade desk manager

Mary, XX System support manager

Carl, XX IT Infrastructure manager

John, XX and YY Security manager

André, XX Project manager

Andrew, YY Project manager

Christina, XX and YY Network manager

FACILITATOR

Soren

A1.    INTRODUCTION TO PQA

Process Quality Assurance (PQA) is a team-building technique for groups of people who are going to cooperate in order to solve a complex task, for example, a Strategic Initiative.

The scope of the task and the group of people to participate in the PQA process is decided by the task sponsor, who must be supported be the PQA facilitator. The result of this decision is a PQA Introduction such as this one, showing core quality objects.

PQA visualizes the complete set of agreed requirements to the solution, the process, and the organization resulting from solving the complex task:

•  The initial scope and conditions of the task signed off by the sponsor

•  The visions and missions of the involved key-stakeholders

•  The Success Factors

•  The Critical Success Factors (CSFs)

•  The required activities to achieve the Success Factors

•  The organization to perform the activities

•  The solution structure and framework

The PQA process is initiated in a PQA workshop. The PQA workshop makes visible the full scope of the task:

•  The initial scope and conditions of the task signed off by the sponsor

•  The key-stakeholders participating in the workshop

•  The visions and missions of the involved key-stakeholders

•  The Success Factors

•  The CSFs

•  The required activities to achieve the Success Factors

•  The workshop participant to facilitate an activity

PQA is one tool for project management, but it does not replace good project management practice.

A1.1    PQA and Destructive Conflict Prevention

If conflicts could be avoided among project participants and between project sponsors and project performers and other involved stakeholders, such a project would have a very high chance of producing a successful outcome.

In order to avoid destructive conflicts, all project participants must be highly motivated for both personal reasons and for creating mutual success.

Such a situation can be achieved by promoting common targets with a related benefit package, which can only be obtained if all participants reach the target simultaneously. Such a situation will motivate and even force the partners to help each other instead of fighting.

Why are all projects not handled in this way?

Because it requires quite some strategic thinking and planning to establish such targets.

When building a bridge common targets are quite obvious, which means that the “no conflict” solution is more process and organization based, which in most cases can be controlled by management.

When building IT infrastructure and information systems in support of private and public business activity, the common targets are much less obvious.

Quite often the resulting solution from such projects does not reveal itself until the final acceptance testing. It therefore becomes a key to the “no conflict” solution that targets are thoroughly defined and agreed to by all project participants and other stakeholders. This holds true especially when we talk about “moving targets,” which is more the rule of the game than an exception.

The project process must be thoroughly defined and the project organization put together in such a way that the “no conflict” solution can and will be reached and communicated. There must be clear rules for how known and unknown risk events and problems are treated organization-and procedure-wise.

PQA ensures a strong team feeling based on mutual respect and commonly agreed decisions within the project organization, which also strengthens its ability to cooperate with external partners. In this way PQA contributes to establishing a situation with less risk of destructive conflict. Nevertheless, the change management procedures while conducting the complex task must be clearly defined as well as involving external stakeholders, which is a strong requirement for the defined activities under PQA:

•  The situation without destructive conflicts is a success factor.

•  The change management process is an activity on its own or imbedded in other activities such as project management and quality management.

A1.2    The PQA Product

The PQA Workshop results in a documented outline project plan with agreed result requirements and outline responsibilities. The complete project plan is not detailed defined, estimated, and scheduled until immediately after the PQA Workshop. Depending on the organizational level of the PQA participants (PQA can be used by top management for 5-year planning or by a task force for a single project), the outline project plan can result in several projects requiring their own PQA Workshop for team building and detailed planning, or it can simply result in an agreed task list.

PQA standard documentation ensures a result that is easily interpreted and understood. It is a good foundation for later status reporting, project reviews, and project evaluation. The PQA Workshop documentation is used for:

•  Introduction of the project to future project participants.

•  Introduction to management, who will deliver required resources to the project.

The PQA documentation produced after the workshop visualizes estimates, budgets, and risk.

A1.3    The PQA Organization

The key-stakeholders to participate in the PQA Team are selected based on criteria such as:

•  Competence within the scope

•  Relevance within the scope

•  Completeness of knowledge pertinent to the scope

Together the PQA Team participants cover the complete knowledge and experience required in order to solve the task at hand.

Even though the participants in the PQA Workshop might not possess all required skills and competences themselves, they must be able to evaluate the skills and competences required to complete the task.

The participants in PQA are at best selected from comparably equal levels of management, responsibility, and authority within their respective organizations. During PQA, all team members are peers irrespective of their basic organizational level in order to be able to express their ideas unbiased by management pressure.

The PQA participants are trusted by the project sponsors in order to be able to get approval of their project plan.

A1.4    The PQA Process

PQA requires maximum active participation from each participant. It is impossible to be a passive passenger in the PQA process. By “forcing” the participants to listen actively and respectfully to each other, it is ensured that every participant achieves maximum inspiration from the other participants.

All participants get to understand and respect their own and the others priorities, requirements, and wishes. In this way, the project group builds a mutual understanding of the project scope, complexity, and target, which can be communicated to interested parties outside the PQA participating core group.

PQA ensures synergy.

The PQA process ensures that resulting documentation is produced “on the spot,” which reduces the risk for later manipulation by a creative author of minutes. The result reflects precisely the agreed conclusion.

Documentation, which requires specific skills and competencies for its production, is done after the Workshop by involving people with the necessary skills and competencies. Such documentation encompasses activity descriptions for each activity outlined during the workshop.

A2.    THE SCOPE OF THIS PQA

In order to be able to control the complete XX IT environment of hardware (mainframes, PCs, routers, networks), software (operating systems, databases, TP monitors, middleware), and applications (end users and Back Office), this environment must be identified, managed, and controlled.

Identification means that any relevant item can be overviewed from a single point of reference based on access to central or distributed information about the whereabouts and condition of the item.

Management and control means that no item can be in conflict with the overall objectives of XX concerning availability, reliability, safety, and maintainability of applications and solutions. Whenever an item is one of the keys to the performance of a user application, it must be ensured that any deviation from expected item behavior is discovered and dealt with.

During this PQA, the participants shall define the solution, process, and organization requirements concerning the establishment of the XX IT enterprise management within the framework of the YY project already executing.

During the PQA, you will get the opportunity to describe and get documented how you think the XX IT infrastructure success can be ensured. You will get inspiration from and give inspiration to the other PQA team members.

As a result, we will have an outline description of all the necessary and sufficient activities, the organizational preconditions, and the complete solution.

A2.1    The YY Project Situation

The YY project is delivering a fully functioning web-based bank supporting private financial transactions performed by the bank’s clients, and transactions performed by the bank with respect to stock exchanges and related services from other systems such as SWIFT and cooperating banks.

Although some functional experience can be drawn upon from the current private banking system, the YY system must be considered a completely new application based on new technology.

The YY system is currently in Acceptance Testing state, which should imply that most solution components have been developed, tested, and approved on their own and integrated with other relevant components. This is not quite the case, which is a major risk and challenge concerning the future performance of the YY project.

Until now, the requirements concerning XX IT infrastructure support have only been outlined on a very high level. The current YY test environment in XX is by no means representative of the future YY IT production environment. All testing is currently concerned with business functionality, not with IT environment performance or availability.

A2.1.1    Many Developers’ Results To Be Integrated and Approved in Parallel

The YY solution is designed and developed by many individual contributors and vendors. Each vendor’s components are going to integrate and interact with other vendors’ components.

Until now it has been impossible for YY to obtain documentation for how the different components are going to interface with each other and what processes and applications are going to be interfaced, used, developed, handled, and controlled by XX.

The YY Acceptance Testing (SAT) is taking place in parallel with Proof of Concept (POC) testing ad hoc using IT infrastructure elements at XX. The testing results in ongoing delivery of new or enhanced or corrected components from the different contributors to the YY solution. This situation makes it very difficult to guess the final outcome of the processes and components that must be delivered by XX.

A2.1.2    XX Not Actively Involved in Project Planning

Because the focus of the YY project until now has been business functionality and because the SAT testing situation is less than optimal, there is very little time devoted to planning of the XX IT infrastructure implementation.

It is of course important that the business functions are consistent, valid, and user friendly before they are launched.

But it is to a very high degree the IT infrastructure that shall ensure whatever availability, reliability, and safety that will be required for the final YY solution.

It is therefore a very high risk to the whole YY project that the XX IT infrastructure is not properly defined, documented, and developed at this late stage of YY SAT testing, especially regarding the lack of experience within XX with respect to the established or expected YY technology, transaction quantities, and transaction frequencies.

Before launch it must be proved that the YY solution is technically robust and well performing.

A2.2    The YY Enterprise Management Opportunities

Available Enterprise IT Management System software can allow XX IT to establish the IT infrastructure that will be required by the YY solution.

Standardized Agent and Manager Software from equipment manufacturers and from CA can allow XX IT to see the most relevant events and to react to these correctly and in time in order to keep the business applications available with the highest possible performance.

XX IT or its vendors can build customized agents and managers for direct surveillance and control with all critical processes not otherwise managed.

Time critical actions in response to events can be automated. Workload Management (job control), Storage Management (back-up), Help Desk, and even contributions to end user solutions form natural parts of the future overall XX IT Enterprise IT Management System Strategy.

The establishment of the future Enterprise IT Systems Management information system solution is almost as complex as the establishment of the YY business functionality and customer service. Please refer to the attached “Enterprise Systems Management” whitepaper from XX IT.

Only a close cooperation between business interests and IT interests within the YY project can ensure a future complete XX IT Enterprise IT Management System solution that performs according to YY and XX IT expectations.

A2.3    What Are We Going to Achieve in the Workshop?

In the PQA workshop we shall consider all the outstanding activities to be performed by the YY project team in order to ensure delivery of the full YY solution for commercial usage.

We shall formulate why and how and when close cooperation between YY business-processes implementation and XX IT infrastructure implementation can bring about the optimal YY solution.

The participants in the workshop must formulate the requirements concerning:

•  The future working condition in the YY organization with complete XX IT Enterprise IT Management System solution implemented.

•  The adjustments to the YY project organization, processes, and products, which can ensure an efficient cooperation between all future YY project participants, as well as considering the involvement of external vendors.

We will not formulate specific technical requirements to the future solution as these requirements will be precisely defined by competent resources task by task later on.

However, we will define and visualize the targets for these competent resources to be able to work effectively and produce efficient solutions that can and will be accepted by XX IT and YY management. Relevant ideas and suggestions are welcome.

A2.4    How to Prepare for the PQA

Please read the “Enterprise Systems Management” whitepaper from XX IT before the PQA Workshop.

Based on ideas formulated in this paper and on your own ideas and expectations concerning the implementation of the future PFS production environment of systems facilities, support, standards, and environment administration, you must describe your vision of the future YY and how you interpret the mission of the YY project team.

Think about what you consider the most extreme case of success for the development and implementation of YY and the XX IT infrastructure. Describe the factors especially relevant to your responsibilities and capabilities within the YY project team.

A2.5    Areas of Concern

The following areas of concern should be considered:

•  Are deliverable success criteria defined?

•  How are reliability, maintainability, and availability defined?

•  With what other systems do we integrate?

•  Who is the user of the product?

•  How should the XX IT infrastructure communicate with the users?

•  User involvement?

•  The implementation process?

•  Use of methods, techniques, and tools?

•  Availability or development of standard documentation templates?

•  How do we ensure compliance with standards?

•  What standards do we have to develop or implement?

•  Education, training, and coaching requirements?

•  Common reasons for IT failures and their prevention requirements?

•  What is the biggest challenge concerning Back Office operation?

•  What are the most common recovery problems encountered and what are their prevention requirements?

•  Who should participate in the implementation of the XX IT infrastructure?

See you in XXXXXXXXXXX.

Yours Sincerely,

Peter Soren

A3.    PQA AGENDA

A3.1    Verbal Introduction to the PQA

The verbal introduction to the PQA comprises the same information as this written one, but allows for a discussion of the scope of the PQA Workshop. Also it permits the PQA facilitator and the PQA sponsor to present who they are and to explain their own and the participants’ roles during the Workshop.

A3.2    Definition of Vision/Mission

Definition of vision/mission is done individually by each PQA Workshop participant. The participant presents a personal view on the expected result and the expected business benefits.

Each individual vision is written down with the name of the author attached to it. It is one of the keys to the cooperation and mutual respect of the team members that they understand the motivating factors of the others.

It is allowed and even recommended to ask for explanations of vision/mission statements, but their relevance or correctness can never be challenged.

People will and shall tackle problems in different ways. We just have to know what the cases within the PQA Team are in order to be able to play on each participant’s strengths in order to obtain maximum creativity and synergy.

A3.3    Suggestions for Critical Success Factors

The Success Factors express what the PQA Team thinks should be the quality of the result of its work. The Success Factors also express by what the group expects that other people will evaluate the project result.

The Success Factors are identified by letting each participant in turn suggest one Success Factor. All suggestions must be true, relevant, and valid, but full unanimous agreement is not required.

This suggestion process is continued until no one has more suggestions. Normally 40 to 60 Success Factors are identified.

A3.4    Definition of the Critical Success Factors

The suggested Success Factors are grouped into CSF classes in such a way that the suggested Success Factors belonging to a class define the class’s CSF expression. There will be from 5 to 9 CSFs. Full unanimous agreement of all PQA Workshop participants is required on each CSF formulation. All suggested Success Factors must belong to at least one CSF class.

A3.5    Outline of Activities

This process produces the CSF matrix shown in Table A.3 under Section A5.2 that shows how the outlined activities contribute to the fulfillment of the CSFs and their Success Factors. Participants in turn can suggest any number of activities which they believe are required to ensure the realization of the CSFs and their Success Factors. Each activity supports at least one CSF. How the activity will contribute to the fulfillment of the CSF and its Success Factors is defined after the Workshop.

The facilitator negotiates the level on which the activities are defined in order to ensure that a too detailed activity level or too high activity level is not reached. The defined activities must be agreed to be on an equal level in the future Work Breakdown Structure (WBS) that will be defined after the Workshop.

When no more activities are suggested, each suggested activity is cross-checked against the CSFs, which it supports. In order to control the completeness of activities, each CSF is then checked in order to verify that the suggested activities together are adequate to ensure fulfillment of the CSF and its Success Factors. Missing activities are added and evaluated against the CSF.

During the activity definition session it is important to ask the suggesting participants to define exactly what they mean by a suggested activity unless it is absolutely self-explanatory; however, this is rarely the case. After the workshop, each activity must be exactly defined by the person who becomes responsible for the activity. It is highly recommended to take notes during the Workshop in case you become the responsible facilitator for an activity.

A3.6    Assignment of Responsibility

Assignment of responsibility for the definition, risk evaluation, estimation, and planning of each activity is next. Assignment must be given to a participating PQA Team member, never to an external organization unit. After the Workshop, each assigned team member must within a set time frame produce a complete activity description with activity definition, task list, resource requirements, time and cost estimate, risk evaluation, and plan information about predecessor and successor activities.

A3.7    Evaluation of the Quality by which the Activity Might Already Be Carried Out

Some suggested activities might already be executing or defined by another PQA Team, while others are new to the PQA Team. Activities that are performed satisfactory are of less interest to the PQA Workshop, but the PQA Team needs to be aware of this. Other activities should be evaluated according to their current performance in the organization. Their “value” is stated as:

0	Activity not done
1–2	Activity known but unstructured performance
3–4	Activity performance structured, but to be improved
5	Activity probably satisfactory performed

A3.8    Review Planning

It is absolutely necessary to decide on the date of a review meeting with all PQA Workshop participants attending. In the review meeting, all Activity Descriptions are approved before the final WBS and schedule are drawn up.

A person must be appointed to be responsible for coaching the authors in their usage of the Activity Description form and for collecting and distributing all Activity Descriptions at least one week before the review meeting.

This person will also organize the rewriting of the PQA Workshop result on standard forms.

A4.    AFTER THE WORKSHOP

A4.1    Detailed Define and Estimate Activities

Each person assigned as responsible for activities makes an activity description for each of these activities. When doing this it is important to assess all thinkable risks concerning estimates. Availability of resources with the proper skill and experience or the ability of sub-contractors to deliver the required quality on time are the most common risks in software development projects. If new technology is involved, the ability of the organization to get and control it is a major risk area. The consequences of risks should be explicitly stated in the description of involved activities.

A4.2    Build the Work Breakdown Structure

The activities are sorted into their natural sequence and they are grouped according to the WBS groups of work, for example:

•  Implementation activity

•  Development activity

•  Quality Management and Project Management activity

These activities are further broken down into specific deliverable elements. In other cases, WBS can be organized by deliverable component, where each deliverable component has activities for implementation, development, and quality management.

In this process, milestones are identified and agreed to by the PQA Team and the key-stakeholders and sponsors.

A4.3    Build the Project Plan

After having organized the activities into a WBS with phases, activities, tasks, and milestones, the next step is to define dependencies between tasks and allocate resources to tasks.

The last step is to optimize the plan in order to meet milestones and deadlines within resource constraints and cost budget.

The project plan and the complete set of PQA documentation is approved by the sponsors and the key-stakeholders before it is distributed to other participants.

A4.4    Initiate the Work

The work can be initiated when all project participants have received the approved plan and PQA documentation.

Before initiation it should be decided what kind of information is needed by the project and what kind of information is needed from the project. The decisions should be documented in a distribution list for the documentation and in a documentation description showing the structure and content of the information as well as who is responsible for its production and its distribution.

It must be assured that the project is properly managed within the project management rules of the organization. Quite often these rules have to be established and documented explicitly within each project. The general rule is that every project gets its own culture, which implies a need for its own procedural handbook.

A4.5    The PQA Result

The PQA results produced directly in the Workshop is a set of documentation comprising:

•  The individual vision/mission statement of each participant

•  The CSF and their definition (the underlying suggested Success Factors)

•  A cross-reference matrix between CSF and activities, which also shows activity evaluation and assigned responsibility

This documentation is transformed into standard PQA documentation for distribution to the participants immediately after the Workshop.

After the Workshop the PQA activity list is defined in more detail using:

•  Activity descriptions

•  A WBS

•  A schedule

•  Document definitions

•  Document distribution list

Appointed project managers are responsible for the detailed project documentation creation, the Project Requirements Document (PRD). The PRD makes what is going on visible to key-stakeholders, sponsors, resource management, employees, involved resources, and other stakeholders.

Vision Examples

Visions
Eric Pavier:	We want to be outstanding with respect to usage and implementation of methods and techniques.
John Doe:	Our consultants are rated the best when it comes to project management and analytical skills.

The PQA process has ensured that the involved participants and interested stakeholders have reached a common understanding of the future project.

The full set of PQA documentation is approved in a review. It will be used for later evaluation of the project progress and its results.

A5.    PRODUCED IN THE PQA WORKSHOP

A5.1    The Vision Statements and the Critical Success Factors

The vision statements are listed with the name of the author.

The CSFs are anonymous because most of them are suggested based on the inspiration from all of the team member suggestions. The CSFs are documented like this:

CSF and Success Factor Suggestions

CSFs
1.	A supply service that can be measured and optimized On-time delivery to customers Avoid or reduce the back-order shipments We understand what good delivery service is (it is defined) Improved availability of goods due to better forecasting Efficient support for the customer and the salesperson in the order process
2.	A competent organization Simultaneous adaptation of business, management, organization, and system procedures We need to build an organizational match before installation of the system The users involved are the best we have Ability to handle big, complex, international projects

A5.2    The PQA Matrix

PQA Matrix

A6.    DOCUMENTATION PRODUCED AFTER THE WORKSHOP

A6.1    The Activity Description

The Activity Description is done for each activity defined in the PQA matrix.

Activity Description	Activity ID:
By:	Date:
Scope	Describe why this activity is required and what its areas of concern and responsibilities are.
Deliverables	A description of the expected outcome, e.g., a tender material, a report, or an accepted system.
Purpose	A description of the deliverable quality expectations or of the expected benefits from the delivery of the deliverable.
Responsible	The person responsible for getting the activity done (sometimes the person writing this description).
Resources/Roles	A description of needed roles and their responsibilities and skill and competence requirements. Specific named resources can be applied to the roles.
Task List	Task Description	Estimated Resource Usage
	Scope purpose and product for each task. Required role interaction if not obvious.	Roles/names of resources to perform task with person-hour estimate for each resource.
Time frame	Duration or fixed period.
Risk Assessment	Describe potential events or preconditions that could influence the deliverable quality, the duration, or the estimated resource usage. Think about external factors, which cannot be controlled, and internal factors, which can and must be controlled. Describe the probability of the event (if 100%, it is a problem rather than a risk). Describe the impact of the event.
Dependencies	Reference to activities that must be performed before this activity is performed and to activities that will use results from this activity. Explain if not obvious.

A6.2    The Risk Response Matrix

The Risk Response Matrix is used for control of the completeness of the risk response strategy established while the PQA participants are reviewing the Activity Descriptions produced after the PQA Workshop. The project manager or the PQA facilitator produces the risk list shown in the second row (Risk). The third row shows for each risk the originating activities. In the example, the WBS reference is shown.

During the review, the risk responses are agreed to and listed in the first column. The second column shows who is responsible for executing the risk response, the third column shows the deadline for the response execution, and the fourth column shows the activities involved with the response.

Risk Response Matrix

Project Name
(Who, Date, Version, Distribution list, Approved by ….)			Risk	1. Availability of skilled resource
Response activity	Responsible	Deadline	WBS-ID	2.1.2, 3.1.1
Procure sub-contractors			3.1.1; 4.1.1	*
Hire Java Ace			2.3	*

One response can have a positive or negative effect on more than one risk event, which is shown with a * in the cross-reference cell. One risk event might require more than one response.

The PQA participants ensure the best possible response strategy by controlling that set of responses to a risk is the best possible way to avoid, mitigate, transfer, or share that risk, and by controlling that the full set of impact on all risks by a given response is fully understood and documented.

A6.3    The Work Breakdown Structure

The WBS shows the hierarchy of the project activities.

Here it is shown as indented activities in a Gantt Chart, which also shows the project plan schedule (Figure A.1).

A6.4    The Work Breakdown Structure Dictionary

The WBS Dictionary contains all initial scope information concerning the project, the program, or the strategy execution planned, which comprise:

•  The initial activity scope such as formulated in the PQA Workshop

Introduction.

•  The full PQA Workshop result with participants vision/mission statement, CSFs related to their detailed success factors.

•  The PQA matrix with initial responsibilities and activity quality shown.

•  The risk response matrix.

•  All activity descriptions.

•  The WBS shown graphically as in a Gantt Diagram:

FIGURE A.1
Gantt chart schedule.

The WBS Dictionary is the primary project description, and it is an important base for the project plan.

A6.5    The Communication Plan

The communication plan shows the type of information that will be produced in the lifetime of the project, the program, or the strategy execution.

For each information type it is shown:

•  Who is responsible for producing the information. Who is responsible for approving the information before it is made available to the receivers.

•  The document standards to follow or the form of the information suggested, for example, minutes of meeting, presentation on Web or in meeting, training material, solution documentation, etc.

•  The technical whereabouts concerning the information, that is, where it is stored, in what format, how it is protected, how access is ensured, etc.

•  What is the content of the information and what are the origins and the required quality of this content? The quality is what the receiver expects to see and how this quality is ensured.

•  The frequency of the information or the events that trigger the production and delivery of the information.

•  The receivers of the information or, alternatively, who must have authority to view the information.

•  How, who, and when to inform the receivers about the availability of the information.

The communication plan is at best prepared as part of the Activity Description review process.