Strategy Process Quality Management
Once our Strategic Initiative teams have been established, it is time for them to get to work, that is, to plan the delivery of the strategically aligned solution and to deliver it by executing the plans.
In order to succeed with the solution delivery, the teams establish a complete set of plans that with the highest possible probability lead to solutions accepted by the stakeholders.
Planning and plan execution of Strategic Initiatives is not just Project Management; it is, to an even higher degree, Risk Management:
The objective of Strategic Initiatives is to reach FUTURE situations and conditions with high PROBALITY that will provide the IMPACT wanted by the involved stakeholders.
Strategic Initiatives are risk. They can fail or succeed. In order to optimize the chance or probability of success, we apply risk management to the Strategic Initiatives. Project Management on its own will not do the job.
Risk Management performed efficiently can allow the teams involved with Strategic Initiatives to build plans that have a higher probability to achieve the solutions and results (the impact) demanded by the stakeholders.
In this respect, Strategic Initiative Process Quality Assurance (PQA) is Risk Management and in the work that we have performed, Risk Management is PQA.
PQA and Risk Management adapt to the same basic definition. Risk Management comprises methods, standards, tools, and techniques that allow the performing teams to:
• Identify opportunities (risk with positive impact on stakeholder benefits) and threats (risk with negative impacts on stakeholder benefits).
• Analyze the risks for their cause and impact.
• Evaluate and quantify the risks with respect to their probability and their impact.
• Respond to opportunities by planning for them to come through.
• Respond to threats by planning for them to be removed or to be mitigated.
Risk Management processes are not finite; they continue throughout the Strategic Initiative and help the teams to survey the risk situation of the initiative.
Please remember that we are always faced with pertinent unknown unknowns and unknown knowns that are ready to surface at any point in time in the future of our Strategic Initiative.
Risk responses are always built into the project plans. You respond to risk by adapting your plans to:
• Accommodate the best possible resources.
• Utilize the best possible procedures, standards, and techniques.
• Adapt the solution to be SMART (Specific, Measurable, Achievable, Realistic, Time bound).
• Ensure satisfactory funding by efficient stakeholder communication.
I admit that I am not in favor of artificial elements such as Residual Risk and Contingency Reserves based on more or less good exposure calculation:
Exposure = Σ(Impact – value × Probability of Risk – event or condition)
Personally, I prefer to call things by their real name:
• Simply opportunities and threats—they are there if they are documented in the risk list.
• Funding instead of reserves—funding is decided by the sponsor and will depend on factors other than risk, such as trust, need, and capability. I have never met a sponsor who provided “free” reserves to any project manager, but funding after serious negotiation, yes!
The symbiosis of PQA and Project Management is well established in many corporate standards, but funny enough not in the PMI and Prince standards, where Risk Management is defined as a sub-management process to Project Management.
One of the major Swedish international concerns in the Information and Communication Technology industry uses Risk Management as their initial process and of course continues to apply Risk Management to Planning and Change Management in the full lifecycle of their projects and programs.
I had the opportunity to train their development engineers in PQA. It was in this context that we discussed how Risk Management should be applied to Project Management.
The Strategy Governance Team establishes and maintains the master plan that binds together and integrates all the subsequent plans. The Strategy Governance Team establishes the master plan as the top level PQA Team. In this top level PQA process, they establish the first level of subordinate PQA Teams that together ensure the delivery of the required strategically aligned solution components.
PQA is used to ensure the quality of the initial plans, but it is also used to ensure the quality of changed plans, especially in connection with PQA review workshops that are used to respond to risk and to adapt the plans to required changes decided by the Strategy Governance team.
Conceptually PQA always starts with the opportunities. The logic of this is that if you cannot find a feasible plan based on opportunities, there is no need to look for risk because the Strategic Initiative is already doomed to fail. If, on the other hand, you have at least one way to ensure the success of the Strategic Initiative, you have a sound base for optimization by searching for and adapting to other opportunities and risks. PQA works like this:
• In order to establish a feasible plan, PQA initially looks primarily at opportunities to reach the targets. This opportunity-based plan has a very high probability to deliver results that are what the stakeholders want; that is, if the threats were not there, which of course they are.
• Under the planning of this opportunity-based project or Strategic Initiative, the stakeholders and resources to be involved with initiative execution uncover the threats and sometimes new opportunities, but the focus here is threat identification and threat analysis.
• The opportunity-based plan is adapted to respond to the threats in order to ensure the highest possible probability of success from the Strategic Initiative, which is continually adapted to the future risk situation.
PQA is the method for Strategic Initiative establishment and planning based on intensive teamwork in the PQA Teams with brainstorming that documents the agreed Strategic Initiative for implementation.
Agreement to the established objectives for the Strategic Initiative is ensured by active involvement of all pertinent and available knowledge from inside and outside of the organization in the PQA process.
PQA ensures:
• Identification of the Strategy sponsors and other key-stakeholders
• Establishment of the agreed strategy with detailed objectives, Strategic Initiatives, teams and team organization, management, and communication that can ensure the success of the strategy under fast changing conditions and high risk
• Establishment of standards for processes and documentation that can answer these basic questions:
• Where we are?
• Where do we want to go?
• Why do we want to go there?
• How do we want to go there?
• The answers are given in terms that can be easily interpreted and agreed to by all involved stakeholders
• Implementation of the strategy with timely execution of decided
Strategic Initiatives, timely measurement and approval of results and benefits, and efficient change management in support of strategy governance
3.1 STRATEGY QUALITY MANAGEMENT
The PQA method comprises a proven set of tools and techniques that are used to assure the quality of Strategic Initiative processes. However, PQA cannot ensure the quality of the entire strategy on its own. For example, a simple question such as “What is the status of the Strategic Initiative progress?” cannot be answered by PQA. The reason for this is that PQA as a Risk Management-based method is looking ahead. PQA can tell you what the probability is to be on the right way to success in two weeks if this or that opportunity is pursued and this and that risk is avoided or responded to well.
You need supplementary procedures and tools to PQA to perform Strategy Quality Management (SQM), for example, if you want to know where you are compared to where you want to be while executing a Strategic Initiative:
• Project and program tracking is based on a number of performance indicators that can tell you if an activity is delayed, if the project or program is delayed, and quite often if this delay is curable, that is, if changes to the baseline are needed.
• Analysis of information system requirements and solution design is a strong foundation for time and cost estimation. The developers and implementers of the solution can give you reliable feedback about solution quality progress related to usage of resources and funds that can be used for change management, where PQA comes back into the picture.
• Breaking the delivery down into manageable Work Packages based on easily verifiable use cases that are not started, in production, or delivered makes it possible to build Work Breakdown structures for agile solution development and implementation that ensure visible progress and fast and reliable reactions to change requests.
Other performance indicators can be based on:
• Deadlines for access to needed resources and sufficient infrastructure
• The quality of solutions based on, for example, number of failed tests and outstanding errors
• Number of outstanding compliance rules to adapt to
• Contractor behavior versus Scope of Work
• Earned value versus planned costs
The methods, tools, and techniques that we use to ensure the quality of the strategy over its entire lifecycle besides PQA comprise the following:
• SWOT (Strength, Weakness, Opportunity, and Threat) analysis is performed to fully understand the conditions of the corporation (market, organization, finance, technology, etc.). The SWOT analysis, if well performed, allows corporate leadership (the strategy sponsor) to establish the initial scope of the strategy. The initial scope comprises:
• The corporate situation in its market—both current and potential
• Competition—both current and potential
• The strategy stakeholders
• The strategy objectives
• Why is always explained.
• SWOT is used in the preparation of PQA. You need to know where you are in order to be able to navigate to where you want to be.
• In the initial phase of Strategic Initiatives, the scope of the strategy does not need to be very precisely formulated because one of the objectives of PQA is to define the precise scope of the strategy under future conditions that are not known while the initial Strategic Initiatives are established.
• However, it is important to understand the situation of the strategy (the why) in order to be able to choose the most pertinent stakeholders for the “no excuse for failure” strategy, and in order to be able to verify later on that the reason for the strategy is still relevant. If the strategy is based on fear for competition that has ceased to exist, it might be time to build a more aggressive strategy.
• Strategy implementation and governance use classic portfolio, project, and program management methods to plan, schedule, and track the progress of solution implementation. In this respect, we are compliant with PMI and Prince Standards and to the best of my knowledge with the Swiss Hermes Standard.
• In this context, procurement and contracting of external resources for implementation of COTS-based solutions is covered by an example without any discussion of general legal terms and conditions such as it is done in, for example, the PMI PMBOK standard. The sole purpose here is to ensure good team building and low risk delivery of results where sub-contractors are involved.
• Change Management and PQA used in the context of portfolio, project, and program management ensure timely adaptation of the strategy as required in light of unexpected results, conditions, and events.
• Under delivery of strategy solution components, the Coffee Bean methods are used. The Coffee Bean methods ensure ongoing and timely control with the development and implementation of tangible deliverables agreed to by the strategy sponsor and the teams involved with the Strategic Initiatives. The Coffee Bean offers a consistent framework for the Project and Program Work Breakdown Structures. It comprises the standards and methods for Business Analysis (Information Requirements Study), Solution Design (Object Lifecycle Analysis), Agile Solution Development, and Solution Implementation (Accept-Testing).
It is obvious that the needs of corporate stakeholders are very different, and most often inconsistent and contradictory. Nonetheless, corporate leadership and management establish a strategy that they can defend, that is, that can be explained to and accepted by any stakeholder.
In order to solve this task, a set of commonly accepted strategy quality objects are required for strategy establishment. These quality objects have the following characteristics:
• They are tangible.
• They are measurable.
• Their validity and pertinence is agreed to by all stakeholders.
• The quality objects can express all stakeholder needs.
The three basic quality object classes with which we work are:
• Solution
• Process
• Organization
The three quality object classes represent a complete classification of elements that are explicitly defined for any project, program, or business activity performing partial or complete implementation of the corporate strategy.
• The solution can be any combination of products, infrastructure, technology, situations, conditions, business processes, requirements specifications, and organizational elements required to satisfy the needs of the stakeholders.
• The process comprises all activity required to develop and implement (deliver) the solution in time and in compliance with pertinent internal and external standards and legal conditions. The process allows the corporation to optimize the tools, methods, and procedures used in order to obtain the best possible efficiency, for example, using agile and Lean principles whenever possible.
• The organization encompasses anyone directly involved with establishing and implementing the corporate strategy whether internal employees and managers, external consultants, subject matter experts, sub-contractors, or legal and public bodies such as local and national government and unions. The structure of the organization ensures the opportunity to get a beneficial classification of business or working processes and their demand for skills and competences, while the culture of the organization caters to the extremely important communication required to lead, manage, plan, and execute Strategic Initiatives to deliver expected results and benefits.
PQA and other SQM processes such as outlined above ensure completeness and sufficiency of the solution, the process, and the organization required to achieve the benefits expected from implementation of the strategy.
In the context of strategy quality, we use Success Factors and Critical Success Factors (CSF) to establish a valid and complete definition of all quality objects’ attributes.
A success factor expresses a pertinent wanted and needed attribute of one or more quality object, while a CSF is a class of success factors. Success factors cannot be processes or questions; they describe an attractive situation or event, which forms part of the stakeholder’s visions.
3.2.1 Strategy Quality Object Attributes
The three basic quality object classes can be further subdivided into more specific quality object attribute types that are addressed by the corporate strategy and that make it easier to understand and evaluate the completeness of the corporate strategy for the involved stakeholders.
The attribute types can be specific to the strategy situation, but in most cases, they will fall under the nine attribute types shown in Figure 3.1.
During the PQA-based definition of success factors and CSF, we use a simple rule to control the quality of the success factors:
If any quality object or pertinent attribute is left undefined by a strategic requirement, the resulting strategy will probably not be sufficient.
The PQA team cannot ensure that the strategy as implemented will lead to the expected result if the success factors found under PQA are insufficient or missing. The biggest risk here is that the PQA team does not discover the insufficiencies or the missing success factors before it is too late. In order to prevent or mitigate this risk, it is highly recommended to use an independent facilitator to facilitate the PQA process and to ensure its quality.
FIGURE 3.1
Strategy quality object classes and attributes.
If it is explicitly stated that an undefined quality object or attribute is supposed to be handled as “within known opportunities,” then all stakeholders understand why nothing further is done or needed concerning this quality object.
A high-quality corporate strategy defines all agreed quality object attributes (here, nine in total) precisely with the help of the agreed success factors and the CSF resulting from PQA performed by the PQA Teams involved with the Strategic Initiatives.
3.3 SQM FACILITATION AND INITIATION
SQM is initiated by establishment of the corporate strategic framework that consists of:
• Strategy Sponsor
• Key-stakeholders
• Strategy Governance Team
• The corporate situation of SWOT
• Corporate objectives
• Corporate quality standards
• Facilitation
It is a common mistake to confound corporate strategy with all ongoing and planned activity whether managed in the form of projects and programs or by the line organization management as ongoing business activity.
It is explicitly declared by the corporate Strategy Governance Team or a similar body with the same strategic responsibility that the ongoing planned activities form part of the corporate strategy. In this context, the ongoing planned activities have agreed explicit objectives for their contribution to the corporate strategy success factors.
Day to day business activity governed popularly speaking “bottom up” by line or functional management cannot replace a strategy defined by leadership top down. Leadership will establish strategic objectives that will inspire management to optimize their business operations, but that does not mean that the sum of the business operations as performed equalize the strategy.
The Strategy Governance Team comprises as a minimum the strategy sponsor coached by an experienced facilitator.
At best, the Strategy Governance Team represents corporate leadership and consists in this respect of a team of managers with the power and authority to initiate, implement, evaluate, and sign off the Strategic Initiatives to be established.
The Strategy Governance Team knows and understands the conditions and the needs of the corporation in its current situation based on a thorough SWOT analysis or based on the mutual knowledge and experience of the team members.
An experienced facilitator coaches a SWOT analysis in order to ensure a feasible result. The facilitator is at best an independent highly qualified person who is fully trusted by the Strategy Governance team.
The facilitator has at least the following qualifications:
• Is not an employee of the corporation
• Knows PQA and other SQM methods in depth based on own practice
• Has good basic industry knowledge, but is not an expert (or a hero)
• Has strong communication skills
• Has strong empathy
• Has natural authority
The Strategy Governance Team defines the initial strategy scope and objectives based on the individual visions and expectations of the team members.
The strategy is initiated and later on changed if required by using PQA. In this respect, the Strategy Governance Team takes on the role of the top level PQA team.
PQA is the set of processes that are used for establishment of the Strategic Initiatives of the strategy:
• The introduction to the PQA process for the PQA team that performs the PQA processes under a Strategic Initiative
• The PQA Team PQA Workshop that is a brainstorming-based team-building process that results in:
• Individual visions and missions documented and discussed in support of conflict prevention and establishment of mutual respect
• Agreed Success Factors defined and approved to be true and complete
• Critical Success Factors defined and mutually agreed to not leaving one single success factor non-classified
• Required activities to be performed
• Appointment of PQA Team members to lead the required activities
• A plan for PQA result distribution and future reviews of the planning effort concerned with the agreed activities under the Strategic Initiative
• Production and distribution of the PQA Workshop result to the strategy sponsor and the PQA Team members
• Production by the appointed activity leader of the detailed Activity Description for the activity identified in the workshop. These Activity Descriptions are reviewed for compliance with the Activity Description standard by the Project Office and distributed to the PQA Team for review as agreed to in the PQA Workshop
• In a series of review meetings or in a dedicated strategic planning workshop, the suggested activities are approved for initiation and execution. During these reviews, Risk Management is used to identify, evaluate, and define responses to identified risk. The risk responses are improved ways to perform already defined activities combined with identification of new required activities to mitigate threats and pursue opportunities.
The activities are planned in detail once approved. Duration and resource needs and possible costs and dates of required result delivery are estimated with due attention to already executing activity, activity interdependencies, and availability of required resources.
The resulting project plans are approved by the Process Governance Team, which performs the role of process or project sponsor. On strategy top-level, the sponsor is the Strategy Sponsor or the Strategy Governance team, while low-level projects performed by Workgroups can have sponsors appointed by higher level PQA Teams such as the Strategy Governance Team.
Major programs such as the implementation of an atomic power plant, the implementation of a ship’s wharf, or the establishment of a new bank operation will have sponsors and Process Governance Teams with huge autonomous budgets on many levels.
Once executing, the Strategic Initiatives are tracked for progress and quality of delivered results. The status of the Strategic Initiatives is communicated according to the communication plan, not only periodically such as ongoing business operation reporting, but also such as when pertinent deviations from expected conditions are observed.
Important deviations from initial expectation as evaluated by the Process and the Strategy Governance Teams can lead to major changes of the strategy that require new PQA processes and new Strategic Initiatives.
3.4.1 PQA for Destructive Conflict Prevention and Stakeholder Motivation
One of the most important values of PQA is that it can prevent destructive conflicts and improve stakeholder motivation. All stakeholders are motivated for their own personal reasons. PQA visualizes the motivating factors of the key-stakeholders by committing them to document and present their personal vision of the result of and their personal view on their mission during the Strategic Initiative. Furthermore, the key-stakeholder motivation is kept alive and even strengthened by involving them actively in the implementation of successful solutions.
PQA preparation and execution require strategic thinking, planning, and communication in order to establish the commonly accepted (initial) objectives.
The common acceptance of initial objectives and the initial strategy of activities to achieve these objectives ensures an opportunity for a “no conflict” implementation process. The “no conflict” implementation process can be realized long term if it comprises efficient change management.
Efficient change management implies:
• Processes that allow fast and precise tracking (deviation reporting) of all progress
• Procedures that allow deviations to be correctly interpreted and reported
• Procedures that ensure fast and correct response to problems, new threats, and new opportunities
When building a bridge, common targets are obvious, which means that the “no destructive conflict” solution is more process- and organization-based, which in most cases can be controlled by management.
When building IT and Information System solutions, common targets are much less obvious. Quite often, the resulting solution that can be accepted by the stakeholders from such projects does not reveal itself until the final Accept-Testing.
It therefore becomes a key to the “no destructive conflict” situation that IT and Information System solution targets are thoroughly defined, governed (adapted), and agreed to by all stakeholders. This is especially important when we talk about “moving targets.” Agility is necessary.
Besides well-defined agreed targets, the required processes to reach the targets are thoroughly defined:
• Project Requirements Document
• Risk Management
• Tracking standard key figures
• Change management organization
• Change management procedure
• Change implementation procedure
The organization that can execute the processes and deliver the required results is established and governed in such a way that the “no destructive conflict” situation can and will be reached and communicated throughout the implementation of the strategy.
PQA ensures a strong team feeling among the PQA Team members, which strengthens their ability to make decisions, and to cooperate and negotiate among themselves and with external partners.
3.4.2 The PQA Teams and the Cascading PQA Processes
The Strategy Governance Team is by definition the first PQA team. The Strategy Governance Team defines:
• The initial success factors and CSF of the Strategic Initiative
• The main activities required
• The key-stakeholder who is responsible for the success of the activity (the activity leader or the coach of the future activity leader)
The activities defined on Strategy Governance Team level are most often in themselves so comprehensive that they demand their own PQA Team to perform a more detailed PQA process for their establishment with more detailed success factors, deliverable requirements, activities, management, and team members.
The lowest level PQA Teams define activities to be performed by Workgroups that produce tangible deliverables in support of the finally agreed upon strategy benefits.
Based on a cascading PQA process, the Strategic Initiative scope will be fully defined with:
• Expected benefits that can be measured
• Solution components that are agreed to
• Tangible deliverables that allow performance measurement
• Teams and team members and their roles
• Organization for communication and change management
During the PQA-based development of the Strategic Initiatives, all PQA Team members are peers irrespective of their origin within or outside the corporation in question, that is, they have been chosen because they can:
• Formulate the real need of the organization and the benefits to be obtained (WHY)
• Describe the different solution opportunities and their consequences (WHAT)
• Describe the processes and the required resources for a successful result (HOW)
• Select a solution and assign the required resources to achieve it (WHEN)
3.5 PREPARE THE PQA WORKSHOP WAR ROOM
PQA Workshops and Workshop reviews need space for the number of participating people to be seated around one oval table that allows all participants to see and hear each other.
Let us call the meeting room for the PQA Workshop and the PQA Reviews a War Room.
The PQA War Room for initial PQA Workshops requires the following equipment:
• One oval (super-ellipse) or round table
• Flipchart sheets
• Big white board
• PowerPoint presentation equipment
• Walls or windows where you can glue the filled-in flipchart sheets
• Writing equipment for paper and flipchart sheets
• Notepaper for all participants
• Coffee and donut service all the time just outside the War Room
• Lunch service just outside the War Room
In addition to these war room facilities, for PQA reviews you need access to the following:
• Communication facilities that allow you to call and talk to team members and people to be involved in activities and who cannot attend the review meeting. You will need a virtual meeting environment such as Skype, but with good white board facilities.
• The corporate project offices information systems for planning and scheduling.
The War Room can be inside the corporate premises, which is fine for an intensive one-day workshop and disciplined participants.
• No one leaves the workshop outside the agreed coffee and lunch breaks.
• You continue until all activities have been lined up.
If the Strategic Initiative has enough importance, priority, and complexity, you should allow two days for the initial PQA Workshop and do it in a hotel or another professional meeting environment. The rules of workshop attendance are the same.
3.5.1 Running a One-Day PQA Workshop
A one-day workshop can have the following agenda:
8:30–8:45 |
Welcome coffee |
8:45–9:15 |
Introduction to participants with Question and Answer (Q&A) session |
9:15–9:30 |
Coffee break |
9:30–10:30 |
Vision and mission presentation |
10:30–10:45 |
Coffee break |
10:45–12:30 |
Success Factor suggestion |
12:30–1:30 |
Lunch; the facilitator evaluates the suggested Success Factors |
1:30–2:30 |
Success Factor suggestions continued if needed until no more suggestions |
2:30–2:45 |
Coffee with cake |
2:45–4:30 |
Definition of Critical Success Factors |
4:30–4:45 |
Coffee break |
4:45–5:45 |
Outline required activities and evaluate completeness until completeness has been achieved with a good level of the activities |
5:45– |
Close out with review meeting planning and assignment of responsibility for Activity Description |
It is you as facilitator who decides when the right quality of the Success Factors, the Critical Success Factors, the decided activities, the activity responsibility, and the review planning has been reached.
However, it is the PQA Team members who formulate and agree on all elements; as facilitator, you only coach and facilitate.
3.5.2 Running a Two-Day PQA Workshop
The agenda is almost the same as the one-day workshop, but in addition, you plan for an evening activity. If you want a high-quality Day 2, you should keep the alcohol consumption to a minimum during the evening activity, which is possible with physical exercises such as dancing lessons or friendly competition bringing the team members even closer together.
A two-day workshop can have the following agenda:
DAY 1: |
|
8:30–8:45 |
Welcome coffee |
8:45–9:15 |
Introduction to participants with Q&A session |
9:15–9:30 |
Coffee break |
9:30–11:00 |
Vision and mission presentation |
11:00–11:15 |
Coffee break |
11:15–12:30 |
Success Factor suggestion |
12:30–1:30 |
Lunch |
1:30–2:30 |
Success Factor suggestion continued |
2:30–2:45 |
Coffee with cake |
2:45–4:30 |
Success Factor suggestion continued |
4:30–4:45 |
Coffee break |
4:45–5:45 |
Success Factor suggestion continued until no more suggestions |
5:45–7:00 |
Facilitator evaluates the suggested success factors and prepares flipchart sheet for Critical Success Factor definition |
7:00–10:00 |
Dinner followed by whatever you want—games, dancing, wine tasting, etc. |
DAY 2: |
|
8:45–9:15 |
Presentation of the results of Day 1 and eventually adding of new suggested Success Factors with evaluation |
9:15–9:30 |
Coffee break |
9:30–11:00 |
Definition of Critical Success Factors |
11:00–11:15 |
Coffee break |
11:15–12:30 |
Definition of Critical Success Factors |
12:30–1:30 |
Lunch |
1:30–2:30 |
Outline required activities and evaluate completeness |
2:30–2:45 |
Coffee with cake |
2:45–4:30 |
Outline required activities and evaluate completeness until completeness has been achieved with a good level of the activities |
4:30–4:45 |
Coffee break |
4:45–5:45 |
Continue outline of required activities and evaluate completeness until completeness has been achieved with a good level of the activities |
5:45– |
Close out with review meeting planning and assignment of responsibility for Activity Description |
Again, it is you as facilitator who decides when the right quality of the Success Factors, the Critical Success Factors, the decided activities, the activity responsibility, and the review planning has been reached.
3.6 PREPARE THE PQA TEAM FOR PQA AND PQA WORKSHOP
The PQA Workshop is a brainstorming session that follows a specific set of rules of conduct. All invited participants have been selected because of their assumed interest in the subject of the Workshop, and because of their competences in the subject matter.
The PQA rules have been established in order to ensure active involvement of all participants. No one is accepted just as a guest or to listen in passively. On the contrary, the rules are there to ensure the synergy that is only possible if the explicit and tacit knowledge of all participants are provoked to be used.
In order to set the mind of the participants in the PQA Workshop, give them detailed information about:
• The current situation of the involved organizations
• The known objectives of the Strategic Initiative to be planned
• The other team members
• Why and how the brainstorming is performed
This information is presented in two ways:
1. A written introduction prepared by the facilitator and the sponsor and mailed to all participants in the PQA Workshop one to two weeks before the workshop
2. A PowerPoint presentation that is used for opening the workshop by presenting:
Why the workshop is conducted
Why the participants have been selected
Why the workshop rules of conduct are the way they are
The PowerPoint presentation illustrates what has already been presented in the written introduction and allows the facilitator and the sponsors to present themselves and to explain why the PQA Team members have been chosen.
You also have to take into account that the PQA Team members might have had so little time to prepare themselves for the workshop that they have not read the written introduction.
It is very important for the quality of the workshop result that all participants get a chance to set their mind on their workshop involvement before the start of the brainstorming elements.
The PowerPoint supported presentation is also used to answer questions from the participants before the workshop starts. Most often participants have already tried another brainstorming method, and they would like to know why your method is different.
Some participants might have bad experiences from other workshops and some might have had good experiences.
In these cases, I explain that there has been no bad experiences with the PQA Workshop because:
• The workshop is used directly for decision making, not for recommendations that might afterward be ignored or rejected by management.
• PQA is fully backed up by and signed off by management.
• Mutual respect is established in order to prevent destructive conflicts and to allow more than one point of view or personal opinion about a subject.
• Discussion among participants is promoted in order to ensure the best possible value and formulation of Success Factors and Critical Success Factors.
• The selection of participants has been done by the sponsors after thorough evaluation of the pertinence of their skills and competences.
• The workshop initial scope and objectives have been thoroughly documented before the workshop.
• There are strict rules of conduct that allow synergy and that ensure that all participants contribute in an optimal way.
You prepare the written introduction to PQA and the PQA workshop as Coach/Facilitator together with your Sponsor.
If there are key-stakeholders on organizational levels above your Sponsor, it is highly recommended to let these stakeholders sign off on the PQA Workshop introduction in order to avoid any objections later that will have a very negative effect on the PQA Team member motivation.
One of the keys to successful conduct of a Strategic Initiative is that the top-level stakeholders and the original sponsors are involved and activated in the initiative activity whenever this gives them an opportunity to show their personal motivation and their support of the PQA Teams. At best, this involvement gives top-level stakeholders and sponsors an opportunity to proactively promote the importance of their Strategic Initiative.
In most PQA Workshops, these high-level stakeholders (most often a general manager or another member of the board of directors that is also the original sponsor) open the PQA workshop with a short personal speech that explains the importance of the workshop result to the participants.
After the workshop, the original sponsors can evaluate the PQA Workshop result.
On one specific PQA Workshop of high strategic importance where we performed the initial PQA for the pharmaceutical factory implementation, the future board of directors’ team of the factory visited the 2-day workshop after the first day and gave the PQA Team very positive feedback on the intermediate result with visions and Success Factors.
This intermediate feedback from key-stakeholders and original sponsors halfway through the PQA Workshop contributed to the motivation of the participants and the quality of the successful result of the PQA Workshop.
3.7 THE PQA PROCESS AND WORKSHOP INTRODUCTION
The PQA process and Workshop introduction comprise two parts:
• A specific part that describes the condition of a specific workshop:
• Where and when
• Who
• Scope and objective (Why, What, Constraints)
• The roles and the responsibilities of the participants
• How the participants can prepare themselves for PQA involvement
• A common part that explains the rules of conduct of the PQA Workshop and the activity performed after the Workshop:
• How the introduction to PQA and PQA Workshop has been prepared
• What happens in the PQA Workshop
• How the PQA Workshop result is produced and presented
• What an Activity Description is and why it is produced after the Workshop
• PQA Team activities performed after the Workshop
3.7.1 PQA and PQA Workshop Introduction Examples
The PQA and PQA Workshop Introduction examples introduce you to what a simple introduction can look like and the common part that is the same for all PQA processes unless very special conditions demand another way to perform PQA, such as you will see with the private bank information system swap case.
An example of a standard PQA Introduction is shown in Appendix A. A Powerpoint presentation can be downloaded from www. lyngso.lu.
The PQA Workshop has the following agenda:
1. Welcome and PQA introduction to the PQA Team
2. Question and Answer session (short)
3. Participants define their personal visions and mission statements
4. Definition of Success Factors and Success Factor quality control
5. Classification of Success Factors into Critical Success Factors
6. Setup of the PQA Matrix
7. Outline definition of activities and activity quality control
8. Presentation of the Activity Description
9. Assignment of activity leaders to all outlined activities
10. Planning of PQA review activity
Each element is described in the written PQA and PQA Workshop introduction and in the PowerPoint-based PQA Team PQA introduction.
Here I will take the opportunity to explain in more depth why we have chosen to conduct PQA the way we have.
3.8.1 The PowerPoint-Based PQA Team PQA Introduction
The PowerPoint introduction is used to make sure that all participants understand why the PQA Workshop is performed and why they have been invited as members of a PQA Team to perform PQA.
The verbal introduction can be performed by the sponsor or the facilitator or by both. If possible, the original sponsor or another top-level keystakeholder should open the workshop to show how important it is to arrive at a good result.
The first slide presents the participants (Figure 3.2).
As facilitator, you have asked the original sponsor to open the Workshop with a statement about how important the expected PQA result is for the enterprise.
For the original sponsor, the PQA result is a first step to fulfill the expectations and objectives of the enterprise, the establishment of the full Strategic Initiative scope. The sponsor knows what the PQA result looks like because you have informed him or her about this and because the sponsor has had the opportunity to read the written PQA Introduction.
The result seen from the PQA Team point of view is a project plan that outlines the solution components, defines the processes and activities required to establish the solution components, and establishes the organization to perform these activities; however, the team might not be fully aware of this when you start the workshop.
Your objective is to make sure that all participants understand why and how the PQA Workshop is conducted. The participants are invited to ask questions about the written introduction and whenever they want a PQA element explained more thoroughly.
FIGURE 3.2
PQA participants.
You explain why the PQA participants have been selected supported by a slide that shows how we intend to use their explicit and tacit knowledge to establish the best possible plan for establishment of the Strategic Initiative (Figure 3.3).
It is your opportunity to tell the participants that we want their knowledge to be visualized and shared in the context of the Strategic Initiative. You explain what your role as facilitator is and what their roles as planners and decision makers are.
Before you ask the participants to define their vision and mission with respect to the Strategic Initiative, you can introduce what you mean by Success Factors and Critical Success Factors. The participants will use the success factors to document the initial requirements to Solution, Process, and Organization in order for these objects to deliver the expected result of the Strategic Initiative (Figure 3.4).
Some participants might have an idea about what success factors are, but you need to explain how the success factors are used under PQA.
FIGURE 3.3
PQA knowledge sharing.
FIGURE 3.4
Success Factor elements.
3.8.2 Question and Answer Session
In some cases, during the introduction presentation or later on during the PQA Workshop process you will be met by the following question:
“When talking about organization, do you mean the organization of the Strategic Initiative or do you mean the corporate organization?”
The answer is not straightforward, but at the same time it is quite clear:
• The Strategic Initiative organization is a part of the corporate organization, so Success Factors addressing organization can address both.
• Success Factors addressing new or improved corporate organization elements or conditions as a result of the Strategic Initiative are addressing the Strategic Initiative solution, not the Strategic Initiative process.
• Whenever a Success Factor addresses the quality of corporate processes, corporate solutions and products, or corporate organization attributes to be achieved because of the Strategic Initiative, we talk about a Success Factor that addresses the Strategic Initiative solution.
• A Success Factor can address solution, process, and organization at the same time.
Even if you get no questions about the solution-oriented Success Factors, you can explain that the solution fitting the needs of the Strategic Initiative can be very complex, for example:
• A merged organization
• An acquisition
• A factory
• An information system
• A new subsidiary
The solution can even be a combination of these elements. The participants will decide on what the solution is constrained by the initial scope of the Strategic Initiative.
When we performed PQA in the organization that developed and implemented the DANCOIN cash card, the solution was not restricted before the participants had formulated their visions.
One vision was that the cash card completely replaced the wallet of the owner. You can imagine the cash card with club memberships, credit cards, social security ID, etc.
Fortunately enough, the sponsor was there and could state very clearly that the objective was to produce a cash card with anonymous cash to buy newspapers, clothes washing, soft drinks, bus tickets, telephone calls, and other simple consumption—and nothing else.
Obviously, this restriction could have been stated in the scope in the introduction to PQA, but we had not foreseen such an interpretation of the cash card. It is quite important to state what is not included in the scope if this is not obvious.
The discussion led to other interesting solution observations that in the end allowed the team to define all elements of the solution comprising:
• Communication and networking
• Card distribution
• Card usage
• Card reader
• Central transaction clearing
The “simple” cash card solution was complex enough to challenge all PQA team members.
When you explain the process object, you can use the coffee bean methods to explain the different processes that are required in order to develop, implement, and quality/project manage the Strategic Initiative result delivery by using the graphic representation shown in Figure 3.5.
FIGURE 3.5
Process components.
Quality Management and Project Management synchronize Implementation and Development in such a way that the produced solution components, organizational elements, and documentation obtain an agreed quality that complies with the scope that the participants will define and agree to under PQA.
You can show a set of questions that the PQA participants might ask themselves while they define their vision, mission, and suggested Success Factors with respect to the Strategic Initiative (Figure 3.6).
FIGURE 3.6
PQA questions.
FIGURE 3.7
PQA participant visions.
3.8.3 Definition of Personal Visions and Missions
A mission statement describes what you want to do now in order to contribute to make the vision come true.
A vision statement describes what you want or expect the situation to be in the future when the Strategic Initiative or the task has completed (Figure 3.7).
Major corporations often show their vision and mission statements on their public web sites. I have chosen to show examples from Volvo and Novo Nordisk:
Mission and Vision of the Volvo Car Group (from its public web site) Vision
To be the world’s most progressive and desired luxury car brand.
Mission
Our global success will be driven by making life less complicated for people, while strengthening our commitment to safety and the environment.
The Novo Nordisk Mission and Vision are expressed in The Novo Nordisk Way Essentials:
The Essentials are ten statements describing what the Novo Nordisk Way looks like in practice. They are meant as a help to our managers and employees for evaluating to what extent our organization acts in accordance with the Novo Nordisk Way.
Mission and Vision of the Volvo Car Group (from its public web site)
Vision
To be the world’s most progressive and desired luxury car brand.
Mission
Our global success will be driven by making life less complicated for people, while strengthening our commitment to safety and the environment.
The Novo Nordisk Mission and Vision are expressed in The Novo Nordisk Way Essentials:
The Essentials are ten statements describing what the Novo Nordisk Way looks like in practice. They are meant as a help to our managers and employees for evaluating to what extent our organization acts in accordance with the Novo Nordisk Way.
The Essentials are as such an important means for identifying actions, which our organization may take to further align our way of working with the thinking, and values that characterize the Novo Nordisk Way.
• We create value by having a patient centered business approach.
• We set ambitious goals and strive for excellence.
• We are accountable for our financial, environmental and social performance.
• We provide innovation to the benefit of our stakeholders.
• We build and maintain good relations with our key stakeholders.
• We treat everyone with respect.
• We focus on personal performance and development.
• We have a healthy and engaging working environment.
• We optimize the way we work and strive for simplicity.
• We never compromise on quality and business ethics.
Corporate vision and mission statements are developed by corporate leadership to indicate to employees and stakeholders in general where they want the corporation to go and how they intent to arrive at this target— their mission.
Under PQA, we do not develop common vision and mission statements. We leave that role to corporate leadership, who might use some other brainstorming techniques to arrive at corporate vision and mission statements.
Under PQA, the vision and mission statements are personal. Their purpose is to present the participants to each other to obtain mutual understanding and respect.
As can be seen in the previous examples, there is a tendency to mix up vision and mission, and in the PQA case, you are welcome to do the same.
Good vision statements will have some of these features:
• Easy to understand by other participants
• “Paint” a picture of future values
• Express something that you want to happen
• Might be SMART (Specific, Measurable, Achievable, Realistic, Time bound)
• Aligned with corporate strategy and the scope of the Strategic Initiative
• Address the purpose of the task at hand
• Describe the relationship to stakeholders
• Describe what you want to do and achieve
Each PQA Workshop participant defines a personal vision and mission. 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 very important for the cooperation and mutual respect among the team members that they understand the motivating factors of each other.
It is allowed and even recommended to ask for explanations of the vision and mission statements, but their relevance or correctness can never be challenged because it is a personal choice.
People tackle problems in different ways. We like to know what the attitudes are among the members of the PQA Team. Based on this knowledge, we can play better on each participant’s strengths and motivation in order to obtain maximum creativity and synergy.
3.8.4 Definition of Success Factors with Quality Control
The Success Factors express what the PQA team thinks should be the quality of the result of the Strategic Initiative. The result can relate to any solution, process, or organization element that is relevant to the Strategic Initiative or the task (Figure 3.8).
The Success Factors also express what the PQA Team thinks how other people will evaluate the project result.
The Success Factors express opportunity events and conditions or they express that a threat event or condition is avoided, but not how this is done.
To perform an activity cannot be a Success Factor.
You cannot ensure that the result of an activity contributes positively to the value of the Strategic Initiative unless we know what that contribution is, that is, it is the event or situation of this contribution that is the Success Factor, not the activity.
Needed activities are defined after that the Success Factors have been established in response to these, not the other way around.
FIGURE 3.8
Success Factors and Critical Success Factors.
Questions can of course not be Success Factors, but good questions might direct the participants to think about other SMART Success Factors.
The Success Factors are identified by letting each participant in turn suggest one Success Factor. All suggestions must be true, relevant, and valid and, at best, SMART. Full unanimous agreement on each suggested success factor is not required, but the truth, relevance, and validity must be ensured by the team—sometimes simply by reformulation of the suggested success factor.
The process of Success Factor suggestion is continued until no team member has any more suggestions.
All the suggested Success Factors are listed on flipcharts, numbered sequentially without any priority, and visible to all team members once there is agreement about the formulation of each one (Figure 3.9).
When a flipchart has been filled in, it is glued to the wall of the meeting room so that all flipchart sheets and success factor suggestions are visible all the time. In this way, you can avoid too much duplication of suggestions, but to avoid duplication as such is not necessary. A Success Factor suggestion can only be doomed to be duplication if the suggesting participants agree to this.
As facilitator, you are allowed to suggest a Success Factor formulation, but not to change the idea of the suggesting team member. Other team members are allowed to express their opinion and to try to change the idea of the suggesting team member.
FIGURE 3.9
Flipchart sheet with evaluated suggested Success Factors.
A team member can suggest one and only one Success Factor each time it is the turn of this team member to suggest a Success Factor, even if the team member has a whole list of suggestions. This is the reason for allowing team members to steal suggestions from other team members who have not had the patience to wait for their turn.
The bigger the PQA Team the more Success Factor suggestions you will get. A good team size of 7 to 9 participants will yield 40 to 60 Success Factor suggestions.
Once no team member can add an additional Success Factor, you as the facilitator evaluate the results after sending the participants out of the War Room for a lunch or coffee break (Figure 3.10).
For each suggested Success Factor you put one or more circled evaluations on it that declares if the suggested success factor concerns solutionⓢ, processⓟ, organizationⓞ, or any combination of these. For example:
1. More effective Annual Work program preparationⓞ ⓟ ⓢ
2. Improved work program reportingⓟ
FIGURE 3.10
Success Factor evaluation criteria.
3. Knowledge that can be usedⓞ
4. Application Owners can verify their budget and budget performanceⓢ
5. Improved agreed business processes supported by the toolⓟⓢ
You then count the Os, the Ps, and the Ss:
ⓞ: 2
ⓟ: 3
ⓢ: 3
If any O, P, or S comes out with zero or comparatively few suggested Success Factors, you demand the PQA team to suggest Success Factors concerned with these once they get back from their break.
During early phases of a Strategic Initiative, the PQA teams are normally more solution focused than organization and process focused, and the contrary is the case in later phases.
As PQA facilitator, you are patient when the participants discuss the quality of suggested Success Factors. You are not in a hurry and the discussions are important for an open and positive cooperation between participants, so you only coach with suggestions when you have a good idea for a formulation. You should provoke the PQA Team to suggest a number of Success Factors in all categories if necessary after your quality control.
Concerning the PQA Workshop schedule, you are more careful with time control if you do the whole workshop in one day than if you have two days. Normally, the participants will finish the definition of Success Factor suggestions in 3 to 4 hours and the decisions about Critical Success Factors in 2 to 3 hours. However, if you have more than eight participants, it can take longer. A two-day workshop allows for fun and the second day is normally dedicated to critical success factor definition, activity definition, and quality control of the workshop result.
3.8.5 Definition of Critical Success Factors
The definition of Critical Success Factors is a decision-making exercise. Until this session, the team has only had relatively innocent discussions about visions, missions, and Success Factors. Now the team must reach unanimous decisions about how to classify the Success Factors into Critical Success Factors and about how to formulate the Critical Success Factors.
In this process, the team needs your experience and coaching most. Use your quality control classification into solution, process, and organization-oriented Success Factors to find some obvious candidates for the first class to be defined, for example, two solution-based Success Factor suggestions.
Try to make the first class easy to establish and do not hesitate to suggest a formulation that the team members can improve among themselves, that is:
“We get an optimal production environment.”
Such a Critical Success Factor is usable for classification, but it is not SMART because it is not specific.
Ask the participants to suggest a formulation that is SMART.
It might be that the suggested Success Factors that belong to a less SMART Critical Success Factor together make it SMART, but that also indicates that a better formulation of the Critical Success Factors might be possible.
You might have tried out classification based on yellow notes, where each person has the opportunity in a round robin process to group and regroup the notes in silence until no more regrouping is wanted or needed. After this process, you baptize each group to become your Critical Success Factors.
I do not like this method because it does not give good discussions until it is too late after the Success Factor groups have been established in silence. You do get a discussion about formulation, but not about why the Success Factor groups are established the way they are. In addition, you normally do not use a suggested Success Factor more than once, which is not realistic.
The preferred classification method allows the PQA team to discuss each group of suggested Success Factors group by group and formulate the Critical Success Factors during this discussion.
Once a Critical Success Factor has been formulated this way, you easily find other suggested Success Factors to put into the group. Once a suggested Success Factor belongs to a group, you write the group number besides the suggested success factor (Figure 3.11)
Any suggested Success Factor could belong to more than one Critical Success Factor.
The definition of Critical Success Factors close out when all suggested Success Factors belong to at least one Critical Success Factor class.
List the Critical Success Factors on one or two flipchart sheets. Give a number to each Critical Success Factor, but the numbers do not in any way prioritize the Critical Success Factors (Figure 3.12).
Give a number to each Critical Success Factor from 1 to N, where N normally is between 3 and 9.
FIGURE 3.11
Flipchart sheet with Critical Success Factor reference.
The PQA Teams always wonder why there are only from three to nine Critical Success Factors, but this is actually quite logical.
You have three core quality objects that you define for your task at hand or Strategic Initiative, and for each core object you have three attributes that you also want to cover with your Critical Success Factors.
Some Critical Success Factors address more than one attribute, which gives you between 3 and 3 × 3 Critical Success Factors.
If a Critical Success Factor addresses more than one core quality object, I would normally look for an opportunity to split it into better formulated Critical Success Factors so that three Critical Success Factors really are the minimum number that you will see.
FIGURE 3.12
Flipchart sheet with Critical Success Factors.
The PQA Team agrees 100% to each critical success factor. If someone in the PQA Team finds that an additional suggested Success Factor could improve the specificity of a Critical Success Factor, such a suggested Success Factor can and should be added if the team does not object to it.
We cannot lose one single suggested Success Factor in the classification process, that is, all suggested Success Factors must belong to at least one Critical Success Factor.
3.8.6 The PQA Matrix with Activity Definition
The PQA matrix is used for definition of required and adequate activities to ensure the fulfillment of all suggested Success Factors and Critical Success Factors.
The Critical Success Factors are used for control of completeness and outline scope of the activities that the PQA team defines.
Just before the session of Activity Definition on the PQA Workshop, you as facilitator draw up the PQA Matrix on one or two flipchart sheets— the number of flipchart sheets is not important, you can add more if you define many activities (Figure 3.13).
The PQA Matrix is drawn up with a number of columns corresponding to the number of Critical Success Factors plus three columns:
• The first column for the Activity Name
• Each of the following for a Critical Success Factor referenced by its ID number
• The next two for value and responsibility
FIGURE 3.13
PQA Matrix flipchart layout.
The PQA Matrix is written on one or more flipcharts. The rows represent suggested activities described with a simple headline, such as the Activity Name.
For each activity, you indicate with a star or some other symbol that this activity will contribute to the fulfillment of the referenced Critical Success Factor.
If the outline scope is not defined precisely enough by the set of Critical Success Factors referenced by the activity and the underlying suggested Success Factors, then you can add a supplementary comment to the Activity Name.
The activity leader is appointed among the PQA Workshop participants and the initials of the activity leader are added in the Who column.
Each participant can suggest as many activities as the participant finds relevant. As a facilitator, you coach the team to get activities defined on an equal level (e.g., new projects, activities to be further broken down into tasks, or tasks on their own).
As facilitator, you are also allowed to suggest activities.
The PQA Matrix document can look like this:
The participants control the scope of each activity by entering a * under each Critical Success Factor that will be addressed by the activity.
Do not enter * where only indirect relations between Critical Success Factor and activity exist because this might lead to * in all cross-reference points.
If you can enter * under all Critical Success Factors, it is a sign that the activities have been defined on too high a level.
Once all the * connections have been defined, you check that the activities that address a Critical Success Factor all together can fulfill the Critical Success Factor and the underlying suggested Success Factors.
If some activity is missing, it is added and new * made for cross-reference between this new activity and eventual other Critical Success Factors.
You continue until all success factors are fulfilled by the outlined activities.
You then evaluate if an activity is already executing. If that is the case, you give it a value between 1 and 5 that indicates the following:
0 |
Activity not done |
1–2 |
Activity executing but unstructured performance |
3–4 |
Activity executing with a known manager, but to be improved after PQA |
5 |
Activity executing well with a known manager |
The PQA Matrix activity definition session is closed out for each defined activity with the assignment of one of the participants in the PQA Workshop as activity leader.
The activity leader plans the activity in detail after the workshop and suggests a manager of the activity if such a manager does not already execute the activity.
3.8.7 PQA Activity Description and Assignment of an Activity Manager
On the PQA workshop, you present and explain again how to use the Standard Activity Description before you close the workshop out with review planning.
The PQA team members that have been appointed as leaders of one or more activities define the activities in depth after the workshop using the Standard Activity Description form.
Activity Description, selection and suggestion of resources and appointment of an activity manager are classic project management activities. It is not the purpose of this book or this chapter to explain these in general.
Nonetheless, the content and the quality expectations concerned with the Standard Activity Description are covered next because it is part of PQA.
3.8.8 PQA Workshop Review Planning in the PQA Workshop
The further planning of the Strategic Initiative is done in PQA Workshop review meetings. The PQA Workshop review meetings are new workshops that build on the result from the initial PQA Workshop and previous review meetings.
All participants in the initial PQA Workshop participate in the first PQA review in order to ensure that agreed activities are complete, valid, and consistent to succeed with the Strategic Initiative. It is also important to ensure that suggested deadlines, resource usage, and budgets are realistic and that the suggested results and deliverables are achievable in light of resource availability and other concurrent activities.
It might be difficult to keep a PQA Team on very high strategic level together for PQA reviews, but if you succeed in doing it, you can ensure the highest possible probability to succeed with the Strategic Initiative.
When completeness of the PQA Team cannot be achieved for a review, cancel or postpone the review if one of the unavailable resources is necessary for decision making. The other resources will simply waste their time that could have been better used on other activity.
You can compare the situation of an incomplete PQA Team with the situation of key resources missing for producing an important project deliverable on a project task. If you pursue the task, the risk is high that the work is interrupted or that the result is unacceptable, which inevitably leads to delays and increased cost. In most cases, you do not want to take that chance. It is highly recommended to perform tasks only when required resources are available. This is true for material, infrastructure elements, and human resource resources.
Imagine what happens if you start programming a web-based solution and you have no web access—this would not bring you very far unless you have good test and simulation facilities available. Even with such development facilities, you might get surprises when you execute the program on the real web. Furthermore, if your preferred web programmer who is used to agile development is not available, you will waste a lot of time if you bring in somebody who might be competent but who does not know you or your requirements.
Think twice before you bring in new resources in order to speed up things—most often new resources bring more chaos than progress. If you need additional resources, make sure to plan for it and to allow for them to be competent and to be adapted to your activity. This applies to people and technology.
PQA Workshop review workshops comprise the following types:
• The simplest review workshop type is always done. It verifies that the Activity Descriptions that have been agreed to be developed are satisfactory as a requirements specification for the work to be performed in order to deliver the needed result of the Strategic Initiative. It is verified that each activity does what is required from that activity and that all the activities together deliver the expected result of the Strategic Initiative without doing work twice, that is, that the activity integrity is ensured.
• The more complex form of PQA Workshop review is a risk management based review. Once the task of the simplest form of review has been performed, the Strategic Initiative risk situation is evaluated based on the detailed risk events and conditions such as those that have been described in each Activity Description.
• The most complex form of PQA Workshop review is a planning workshop where the complete project plan for the Strategic Initiative is assembled, evaluated for resource availability, scheduled, approved, and signed off by the PQA Team for further sign off by the sponsor and sometimes by the original sponsor.
In the initial PQA Workshop, you and your sponsor explain these review types and the importance of keeping the PQA Team together until the complete project plan has been signed off.
It is important that the development of Activity Descriptions be performed as fast as possible after the initial PQA Workshop.
It is important that all agreed Activity Descriptions have been completed and distributed to all PQA Workshop participants at least one week before the PQA Workshop review.
The participants who are responsible for the development of the Activity Descriptions get the time they ask for to verify directly with the required and competent resources to be involved with the delivery of the task result:
• That the resources agree with the scope and the solution quality to be delivered
• That the resources can perform the work
• When the resources are available to do the work
• The working conditions the resources demand to be able to do the work
It is important for the scheduling of PQA review workshops that the preparatory work of Activity Description development can be done with good quality.
With this constraint in mind, the PQA review workshops should be done as fast as possible.
The PQA facilitator works with the Project Office or a similar secretarial function to support the Activity Description work and ensure that Activity Descriptions comply with the standard (a standard is described next).
The PQA participants will continue to be a team and they will normally help each other to get the Activity Descriptions done in time and with good quality.
The direct PQA Workshop result is printed and delivered to the participants within two working days after the workshop.
3.9 THE ACTIVITY DESCRIPTION PRODUCTION
The PQA participants who are responsible for the development of the Activity Descriptions have been chosen because they understand the scope of the activity and because they are motivated to coach the planning and execution of the activity, not because they know in detail how the activity can be performed or what the quality of the result can be.
These participants can be the project managers of the activity or they can suggest someone outside the PQA Team to be the project manager of the activity.
Whatever the case, the responsible PQA Team member and the future activity project manager get together with the future Workgroup Team that is responsible for performing the activity and delivering the result of this activity.
The Workgroup Team assists in the production of the Activity Description to be reviewed by the PQA Team in order to ensure valid and reliable estimates and quality expectation.
In some cases, an activity is a big project with many stakeholders and many resources to produce a complex result. In this case, a PQA Workshop introduction to PQA with the Workgroup Team can replace the Activity Description. The activity becomes a sub-project to the Strategic Initiative. In major Strategic Initiatives with several sub-projects, the planning process will take longer.
If the Strategic Initiative involves many external organizations and internal departments, it is investigated if it can be executed as a program with a Program Office.
The Program Office can ensure legal and contractual compliance, tracking, and efficient communication in the governance of Strategic Initiatives facing high complexity of organization and solution.
In all other cases, the Workgroup Team will produce the Activity Description and be committed to the estimates and the scope of the activity such as they have expressed it themselves.
3.9.1 The Activity Description Preparation
The Activity Description is done for each activity from the PQA matrix as well as the ones that will become a new project that requires its own PQA.
For the preparation of the Activity Description, use the PQA result and the PQA Matrix:
In the following example, ML writes the Activity Description for:
3) Define and document the essential project types.
To this end, ML has called the future Workgroup Team together to help with the scope setting, the estimation, and the risk identification.
ML and the Workgroup Team will use the PQA Workshop result that is relevant for this activity to ensure compliance of the Activity Description with all referenced success factors.
2. The system supports optimal project implementation
2 Reliable data that are validated before they come into the system
7 The system is integrated with other information systems, so that the information is coordinated across these systems
8 Visible utilization of resources (billable time versus time spent)
9 The system must make it easier for the users to do planning
17 Utilization of the system gives a measurable economic benefit
19 We get an overview over where we lose and make money, so that we get an improved business focus
22 The invoice foundation appears significantly faster
23 Increased maneuverability
24 Flexible reporting capabilities that show relevant information
25 Each employee has an overview of the tasks that the employee is allocated to and used on
26 Be able to identify potential conflicts and deviations early in the project
33 Bottlenecks are visible
34 Internal and external plans can be maintained in the same place
37 The system is easily adaptable to new methods at WCAT
39 It will be visible if a task is behind or ahead of schedule
45 The system is proactive—it reminds the user about activity that must be initiated
47 No excuse for not being proactive and for not taking initiative
50 We can assess the impact of different projects and project portfolio scenarios
56 The system contains only one truth
57 We get fast and useful final costing of projects
59 The system can highlight the vulnerability relative to essential staffing
65 You can register all kinds of time spent in the system
3. Conformity between our delivered services and the customer expectations
10 Controlled project process with fewer surprises—higher predictability
16 The planned project times are respected
20 At any time we can inform the customer about the status of the costs incurred in the customer’s projects
23 Increased maneuverability
28 Higher customer satisfaction because we deliver what is agreed on time
29 Visible customer deliveries and consequences of the customer’s failure to comply with agreed conditions
31 The system provides a better basis for guiding the customer to an optimal process
36 Better time estimation for proposals (standard time)
40 It becomes apparent who must be notified when there are deviations from a plan
42 All involved stakeholders report problem situations in the system with the assurance that the situations are treated in time
48 We must be able to detect and measure the quality of each process (e.g., agreed with the customer)
5 The solution contributes measurably to increased profitability
8 Visible utilization of resources (billable time versus time spent)
11 Increased reusability of collected data and experience
17 Utilization of the system gives a measurable economic benefit
19 We get an overview over where we lose and make money, so that we get an improved business focus
22 The invoice foundation appears significantly faster
36 Better time estimation for proposals (standard time)
55 We start up with a solution that quickly provides visible benefits and is widely used
57 We get fast and useful final costing of projects
3.9.2 The Activity Description Guideline
Activity |
99) Activity name as this is printed in the PQA Matrix. The number is the activity number from the PQA Matrix. When new activities are established during the PQA Review process in response to risk or for other reasons, such activities get a responsible PQA Team member assigned and an Activity Description is produced by the Workgroup Team to perform the activity and deliver the result. |
||
By: The PQA |
Delivery date: The date the Activity Description was delivered for review. |
||
Scope |
Describe WHY this activity is required and what its areas of concern and responsibilities are in the context of the Strategic Initiative. |
||
Deliverables |
A description of the expected outcome, for example, 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. |
||
Task List |
Task Description |
Estimated Resource Usage |
|
Scope, purpose, and deliverable for each task executed in this activity. Describe why you need the roles that have their usage estimated concerned with this task. |
Roles/names of resources to perform task with person-hour estimate for each resource; also the non-human ones if relevant. |
||
Timeframe |
Duration in days, weeks, or fixed period (between this date and that date). |
||
Risk Assessment |
Describe potential events or task conditions that could influence the deliverable quality, duration, or estimated resource usage. |
||
Dependencies |
Reference to activities that are performed before this activity is performed, concurrent with this activity, and to activities that will use results from this activity. |
||
While preparing the Activity Description, you ensure that all Critical Success Factors and their related Success Factors from the PQA Matrix implicitly or at best explicitly are addressed by the Activity Description.
You can use the scope description and the purpose description of the Activity Description to make sure that the activity deliverables explicitly contribute to the related Success Factors from the PQA Matrix.
3.9.3 Activity Description Example
ML and his Workgroup Team reached the following result, which was presented for review in the PQA Team review meeting after approval by the Facilitator and the Project Office for compliance with the Activity Description guideline.
Activity Description |
3) Define and Document Essential Project Types |
Prepared by ML |
Preparation date: 04.06 |
Delimitation |
This activity does not include the following: |
Products |
A document that describes the essential project types with clearly defined phases, when to change phase, and the distribution of responsibilities. |
Purpose |
The purpose of describing the essential project types is to define and document these in a structured way, and from this to: • Be able to prioritize based on WCAT business objectives. • At any time, be able to see in which phase a project is and who is responsible. • Ensure that the individual employee has an overall view of the phases in essential project types. • Ensure a structured collection of experience-figures for each project type. • Ensure that the descriptions form the basis of the implementation in the COTS. |
Responsible |
JO |
Other resources |
CT; ML |
Sub-activities |
Description of Tasks |
Resource Requirement |
1) Identification of the essential project types. |
JO, ML (4 hours) |
|
2) To carry out the analyses and describe the individual project types a group (person) per project type is appointed. It is the responsibility of the individual group to: • Describe the existing project workflow • Identify the action areas/problems • Determine and describe the ideal project workflow (phases, when to change phase, etc.) • Describe the distribution of responsibilities for the project workflow |
Expected time consumption per group: 2 weeks |
|
3) Configure the COTS system for the essential project types. |
CT, LI, ML, JO |
|
Time frame |
August – October |
|
Risks |
If this project is not given top priority by the management, the resources will disappear from the project. |
|
Dependency on other activities |
This activity can be started independently of other activities. Close coordination (concurrent) with: |
|
This Activity Description is not perfect. The estimates could be more precise and the risks could be better formulated, but as Coach and Facilitator, you should not be too critical with the PQA Team performance. You should expect to accept even less perfect Activity Descriptions for review.
Missing elements, consistency, more precise estimates, and risk formulation can and should be handled in the PQA Review Workshop, where you can share your knowledge and experience with the PQA Team.
The PQA Workshop reviews are carefully prepared by the Facilitator and supported by the Project Office before the review meetings. Activity Descriptions have been approved to comply with standards and they have been distributed with reasonably good quality to all participants at least a week before the review workshop.
The Project Office ensures availability of needed facilities, the required PQA Team members, and the timely distribution of needed documentation to all PQA Team members before review meetings.
You need the Project Office to ensure that the PQA review participants have received the Activity Descriptions in time.
Although review dates and participation have been agreed on in the PQA Workshop, you will meet events and conditions that require changes to the review dates:
• Participants who are committed to perform other activities for valid private or professional reasons
• Activity Descriptions that are more complicated to develop than expected and will require more time to reach an acceptable quality
• Future required Workgroup Team members are not ready to help the PQA Team member to develop the Activity Description, which will be delayed for that reason
Changing review date is hard work that requires a good secretarial Project Office function.
The preparatory work is best performed with access to efficient planning and tracking tools managed and used under the support of the Project Office. With such tools, the estimates become more realistic and the Project Office can prepare for PQA Team planning by:
• Creating the Strategic Initiative as a project in the corporate project database
• Making sure that suggested resources exist in the corporate project database
• Making sure that suggested resources can be used for planning, that is, they are allocated to the Strategic Initiative
• Creating the project plan activities as they are defined in the Activity Descriptions leaving the definition of milestones and phases to the PQA Team decision making
• Creating dependencies between activities as these are defined in the Activity Descriptions
• Suggesting a schedule based on the estimates in the Activity Descriptions and already produce the first warnings of non-availability of resources to perform the activities as wished
• If the corporate project management system comprises risk management, the Project Office can already add the suggested risks to the risk list of the Strategic Initiative project plan.
The Project Office tools and preparation do not replace the PQA Team brainwork, but the Project Office preparatory work saves a lot of time for the Facilitator and the PQA Team during the review, especially if the review is performed in a War Room with a big white board screen connected to the corporate project management system.
• Resource usage conflicts are immediately visible.
• Resource availability to activities is immediately visible.
• Complete activity overview and total schedule is visible and can be played around with.
• Alternative resources can be discussed for Project Manager roles and Workgroup participation.
• Initial risk overview is established and duplicates can be identified.
• Risk formulations can be corrected directly for agreement across the PQA team.
• Risk responses can be related directly to activities.
The Project Office is an advanced secretarial function that looks after how established standards for project management are used in and across projects in the organization.
This means that the Project Office can perform the first Activity Description review simply to control that it complies with the standard form and can be used for creation of the project plan and schedule as a foundation for the first Strategic Initiative baseline.
If you do not have access to Project Office support, you are obliged to establish this support, even if you have to create your own Project Office.
The PQA Team members are able to make high-level pertinent planning decisions based on the delivered PQA documentation, status reporting, Activity Descriptions, and already produced plans and schedules. However, if the PQA Team members cannot see the full consequences of their decisions by using an appropriate Project Office supported planning system, then they are working in the dark and the resulting plan is a waste of time.
3.10.1 The Basic Activity Description Review Workshop
The general purpose of the basic PQA Workshop reviews is to ensure that:
• Suggested activities and their deliverables are within the scope of the Strategic Initiative
• The set of activities is complete with respect to delivery of the expected result of the Strategic Initiative
• Activities do not make the same things more than once (integrity check)
• Activities are executed in the right sequence
• Resources are available for fast and efficient activity execution as estimated
• Effective communication is established in activities, between activities, and between corporate management and activity management
The Activity Descriptions and the PQA Team brainwork will not be enough to reach a consistent plan and schedule that can fulfill all the success factors. You need access to a well-prepared project setup in a project management support system that allows the PQA Team to simulate the consequences of its decisions.
If the PQA Team or the facilitator does not have experience with using the corporate project management support system, they need support from the Project Office during the PQA Workshop review.
3.10.2 The Risk Management-Based Review Workshop and the Risk List
Where the initial PQA Workshop focused on opportunities (Success Factors), the risk management process during a PQA Workshop review focuses on threats and threat response with the objective to establish the most optimal project plan for the Strategic Initiative.
Risk Management with identification, evaluation, and documentation of threats and opportunities and definition and documentation of the response strategy can be performed in a group dynamic process during a PQA Workshop review.
The threats might be classified analogous to the CSF (e.g., Critical Threats), which will make it easier to control the completeness of the responses to the risks.
The risk management-based PQA Workshop review can be done at the same time as basic PQA Workshop reviews if the risk situation is not too complex.
The purpose of the risk management-based PQA Workshop review is to identify the risks, to evaluate the risks, and to respond to the risks:
• Risks are identified with correct formulation (e.g., “If aaa event or bbb condition happens, then consequence xxx will be the result”)
• Risks are evaluated and quantified (exposure = impact value × probability of event or condition)
• A risk response strategy is formulated that can comprise:
• New activities
• Activity integration
• Improved activity performance
• Improved Activity Descriptions explicitly respond to identified risk events and conditions
The identified risks with their responses are documented in the Risk Response Matrix for follow up with the PQA Team and for communication to other stakeholders.
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 on the risk-oriented PQA Workshop review.
The Project Manager or the PQA Facilitator produces the risk list (Figure
3.14).
The PQA participants ensure the best possible response strategy by controlling that the 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, for example, in the concerned Activity Descriptions.
FIGURE 3.14
Risk Response Matrix.
If you have used a method other than exposure calculation to prioritize the risks, you indicate it in a comment and explain how and by whom it was done. This makes it possible for others to evaluate the result that you have obtained.
To assist you in finding pertinent risks for your Strategic Initiative, you can find a number of standard risk checklists with core risk objects on the web. The risk objects that you would look for depend on the scope of your Strategic Initiative. One such list can be found on http://www.misronet.com/risks.htm:
Technical Risks
• Incomplete design
• Inadequate site investigation
• Uncertainty over the source and availability of materials
• Appropriateness of specifications
Logistical Risks
• Availability of resources—particularly construction equipment, spare parts, fuel, and labor
• Availability of sufficient transportation facilities
Construction Risks
• Uncertain productivity of resources
• Weather and seasonal implications
• Industrial relations problems
Financial Risks
• Inflation
• Availability and fluctuation in foreign exchange
• Delay in payment
• Repatriation of funds
• Local taxes
Political Risks
• Constraints on the availability and employment of expatriate staff
• Customs and import restrictions and procedures
• Difficulties in disposing of plant and equipment
• Insistence on use of local firms and agents
When the scope is implementation of information systems, your checklist could look like this:
Internal risk that can be prevented or mitigated by project management during the conduct of the project can be related to:
• Resource availability
• Stakeholder accept
• Resource quality
• Internal organization
• Safety
• Security
• Confidentiality
External risk that cannot be prevented by project management, but that might be mitigated by project management before the project is initiated can be related to:
• Technology efficiency
• Sub-contractor reliability
• Management attitude
• Funding
• Market
• Legal matters
It is recommended that you establish your own risk checklist. Once established it will be an important source of lessons learned to be maintained by all qualified stakeholders.
A risk checklist saves you a lot of time with Risk Management and it ensures better results from your risk-based PQA Workshop reviews.
3.10.3 The Strategic Initiative Planning Workshop and the Project Schedule
The Strategic Initiative planning workshops are PQA review workshops. The PQA result underlying a Strategic Initiative is together with any documented and approved changes to this result the foundation for the planning workshops.
The Strategic Initiative planning workshops will take place regularly, normally once a month, in order to ensure:
• Communication of approved changes and expected changes
• Approval of suggested changes if the PQA Team is on the Strategy Governance Team level
• Approval of change suggestions if the PQA Team is on the Process Governance Team level
• Plan deviations are discussed and corrective actions are agreed if needed
• Risk events that have occurred are discussed and corrective actions are agreed if needed
• New risk or new risk probabilities are discussed and responses are agreed and documented in improved Activity Descriptions and in the Strategic Initiative Risk Matrix
• Resource availability is ensured for the next period by negotiation between project managers and resource managers
• Rescheduling of activities is agreed in case of non-availability of needed resources or in case of delays of required deliveries from related activities
• Agreement is established between project managers of activities and resource providers
Participants in Strategic Initiative planning workshops comprise all involved management of involved resources. This management also comprises the managers of concurrent Strategic Initiatives or other concurrent projects that demand the resources concerned.
You ensure that sub-contractors are available for planning and scheduling your Strategic Initiative.
The Strategic Initiative planning workshops cannot yield a usable result without a fully up to date project management system database supported by the Project Office in support of the meeting discussions and decision making.
Brainstorming is not a method for Strategic Initiative planning and scheduling. Strategic Initiative planning and scheduling is based on facts and management decisions based on full visibility of these facts.
The facts for Strategic Initiative planning and scheduling decision making are the project tracking statistics produced weekly by the Project Office based on progress reporting from Workgroup Team members and project managers. Project Management and Process Governance Teams comment
on the statistics when major deviations from the baseline occur. Deviations from baseline also comprise Strategic Initiative risk situation changes.
If correctly set up by the Project Office and correctly used by Project Managers and project resources, the corporate project management system allows simulation of consequences of decisions made on the planning workshop as a safe foundation for agreement and further progress.
The establishment of improved production methods case in WCAT has already been presented in Chapter 2. Only the result is presented here.
The WCAT case is interesting because the established Workgroups and their projects looked fine originally, but they were not sufficiently strong to survive a sudden change of sponsor.
The new sponsor had ideas that deviated from the PQA result. The new sponsor already knew where to take the organization and the former sponsor’s PQA-based strategy did not fit into this picture.
Irrespective of this situation, my organization still delivered its new COTS system and the order project management information system based on this, but our role as Facilitator was finished.
The introduction to the PQA Workshop had the following initial questions:
• What are the 3 to 5 major problems with the current project management strategy?
• Where can your department be more efficient?
• What do you expect from the new information system?
• What do you expect from other departments in WCAT?
• Who must be involved with the specification of the future WCAT project management environment?
• How is the project management environment serviced in operation?
• How is the new WCAT project environment quality managed?
The PQA result is shown in Appendix B.
The thorough selection of participants ensured a high quality result, where improvements to the resulting business processes and the training of the users in the new methodology were in focus to a much higher degree than the installation and operation of the COTS system. Solution, organization, and process are in good balance.
On this basis, we actually achieved an acceptable solution implementation and we know that the enterprise is still very successful.
3.11.1 Activity Description Examples
A selection of the Activity Descriptions produced after the PQA Workshop for the first review meeting is shown in Appendix B.
The formulation of activities to be performed shows here key-stakeholders of high maturity with a lot of experience. This experience allows the stakeholders to see the risks in a broad perspective.
You will rarely find such a level of quality of pertinent Activity Descriptions from a less mature group, and the number of initially identified pertinent risks is impressive.
3.12 THE BANKING INFORMATION SYSTEM SWAP CASE
The program of swapping all IT and Information Systems in a private bank has been presented in previous chapters.
The PQA process used in this case differs from the standard one and allows you to see an example of a deviation from the standard that accelerated progress early, but created quite a few problems later on.
Once the IT Director had established the Strategy Governance Team and the project had been redefined into a program, the Program Manager and the Deputy Program Manager prepared the initiation of the PQA for this program:
• A non-standard PQA Workshop for the Strategy Governance Team to select participants from departmental management level to define Workgroups and Scope of Work for information system requirements specification.
• Preparation of standard forms to be used for Statement of Work documentation and requirements specifications.
• Introduction (PowerPoint) to be used for opening the meeting where the selected departmental managers were demanded to prepare the PQA Activity Descriptions. The invitation to this meeting was a simple e-mail with the PowerPoint presentation attached.
• Preparation of the initial War Room facility that was just the biggest meeting room available in the building with one big oval meeting table ensuring that all participants could see and hear each other.
• Conduction of the special PQA Activity Description Workshop with duration of only one day.
• Documentation of the PQA Workshop result (PowerPoint) with activities to be performed, Workgroups to perform the activities, and required quality of work results.
• Establishment of coaching and facilitation for the Workgroups.
For the following chapters, this case study contains a thorough business analysis with a quite efficient document standard. The resulting requirements specification allowed fast contracting of sub-contractors.
The case study is furthermore interesting in that it demanded a completely new sub-contractor contract to be developed that after often-heavy discussions was signed by all sub-contractors.
The Program Manager supported by the Corporate Legal department and the IT Director developed the new contract.
The sub-contractor contract allowed the program to progress faster with exceptional results from the sub-contractors and the internal bank and IT organization.
The sub-contractor contract is explained in Chapter 4.
3.12.1 The PQA Non-Standard PQA Process
The initial non-standard PQA workshop was conducted as a meeting of the small and dedicated Strategy Governance Team consisting of:
• IT Director (sponsor with IT budget, technology expert)
• Deputy General Manager (original sponsor with program budget, business expert)
• Deputy Program Manager (solution and COTS knowledge)
• Program Manager (methods expert, facilitator, coach)
The Scope and Purpose of the meeting was:
The core-banking program wants to establish the best possible foundation for Workgroup management, where each Workgroup is responsible for establishment of its business “products” and “processes” to be supported by the COTS systems.
The non-traditional PQA workshop results were:
• An outline of the line organization managers with their areas of responsibility required for allocation of resources to the project organization:
• Manager Fund Administration (Compliance, Settlement)
• Manager Fund Management (Execution, Performance, Pools)
• Manager Investment (Execution, Special Products, Trading Desk)
• Manager Finance (Accounting, Management Information, Reporting)
• Manager Treasury (Profit-Center, Bank Holdings)
• Manager Account Management (Client Reporting, Fee Structure)
• Manager Control Department (Client Static Data, Legal Reporting, Nostro Reconciliation, Treasury Control, Risk Limit Control, Counter Party Control, Lombard)
• Manager Operations (Back Office Settlement/Reconciliation, Corporate Actions, Custodian Management, Broker Management, Securities Static Data)
• Manager IT (Production, Infrastructure, Projects, Solution Support)
• The project organization (to be completed after the Activity Description workshop) will immediately commence the establishment of a complete acceptance test environment. The initial Workgroup work will be simulated Accept-Testing of real life business workflows produced by the Workgroups. The involved Workgroup participants will be asked to produce complete test cases before any future workshops.
• We immediately change the scope of workshops to produce only specific bank products with the quality required by the bank. In other words, we will change the scope from COTS functionality to bank business functionality.
• Each Workgroup will have precisely defined result objectives (agreed with the bank management as listed previously) to be obtained within an agreed deadline. These objectives will make it possible for each Workgroup to set up working sessions and to produce the results whenever this does not disturb the necessary daily work. There is no doubt that the highly qualified and experienced staff required in the Workgroups will have to prioritize their time and make sure to deliver the Workgroup results on time.
• The Workgroup objectives will ensure a complete and feasible Information System solution, where the COTS contribution is precisely scoped and defined.
• Each Workgroup has the capability to:
• Make necessary decisions
• Initiate required work
• Perform the work
• Evaluate the work done
• This does not mean that all persons (roles) have to be available all the time, but it means that all roles and lines of communication are precisely defined beforehand. This will avoid any waste of time waiting for decisions to be made or waiting for facilities to be available.
• Workgroups will cover both business functionality and the IT environment. Assigned resources will typically work in more than one Workgroup, which will contribute to facilitating the communication between Workgroups.
3.12.2 The Non-Standard PQA Activity Description Meeting
The meeting with the departmental managers to establish Workgroups was called by a simple e-mail asking the following questions to be thought about before and during the meeting:
Who are the future users of the solution?
How should safe custody functions be handled and implemented? What do you expect from the user interface?
How do we prevent the common reasons for IT failures?
Who can benefit from participation in project work?
How do you envision the implementation process?
How should availability, reliability, maintainability, and ability to integrate be ensured?
What methods, techniques, and tools should be available?
How should standard documentation be produced?
How can we ensure compliance with standards?
What standards do we have to develop or implement?
What are the education, training, and coaching requirements?
What is the biggest challenge concerning the future business operation?
What is the most common error and recovery problems encountered in the current business environment and what are their prevention requirements?
The very simple document standard to be used was attached to the e-mail with an example.
The General Manager opened the “PQA” meeting, but did not participate otherwise.
The Activity Descriptions developed in the meeting consisted of a PowerPoint presentation with all Workgroups and the business processes they were responsible to document in the form of the agreed Workflow-based standard documentation.
The document standard for the Workflow documentation was presented and explained to the participating departmental managers in the meeting.
The Deputy Program Manager and the Program Manager were declared Facilitators and Coaches for the Workflow writing process. We would support the writers, review, and approve the documentation for inclusion into the requirements specification to be delivered to the sub-contractors. The sub-contractors would be responsible for implementing the pertinent COTS functionality for the bank.
On top of this support, IT was committed to set up a sandbox environment with access to a test environment for all Workgroup participants.
The IT information System test environment was a dump on a specific date of all pertinent database content that could be accessed from all current systems in test mode. It was already possible to execute all business transactions inclusive of usage of external relations such as SWIFT and FIX protocols in test mode.
A similar test environment would be set up for the future COTS systems once these systems had been installed and parameterized for bank usage.
In this way, it was ensured that the Workflow documentation could show real life business processes with realistic screens and reports from the old systems. This contributed to high quality of the requirements specifications.
The Workgroups decided on in the meeting looked quite different from the ones envisioned by the Strategy Governance Team initially. This fact shows the importance of communication and involvement of the most competent persons when building teams and doing PQA. The Strategy Governance Team had done great work to get the most competent managers together to make the Workgroup setup decisions.
The Workgroups became:
1. Establish and Terminate Clients
2. Security Transactions
3. Cash Transactions
4. Derivatives Transactions
5. Corporate Actions
6. Tax
7. Fees (Income and Cost)
8. Control and Risk Management
9. Client Reporting
10. Infrastructure
11. Financial Control
The PowerPoint Activity Description for a Workgroup is shown in Figure 3.15 (Workgroup 2 has been used for this example; the numbers are telephone extensions).
The close out of the meeting was an agreement with all Workgroup managers to meet in the War Room every morning at 9:10 to discuss progress and constraints until all requirements had been produced.
All Workgroups had an end of May deadline, but we all knew that this was more than optimistic. Nonetheless, work progressed with an impressive speed and only minimal delays that were always reported well in advance of the planned delivery dates.
FIGURE 3.15
Bank case Workgroup Activity Description.
The minutes from the first 9:10 meeting and the call for the second 9:10 meeting were:
Mail or call me if your Workgroup will not be attending the next 9:10 meeting, please.
We will discuss important experience from work in Workgroups 2, 1, and 7, who have initiated their work. Any other work experience is also presented and discussed.
The 9:10 meeting agenda:
1. Workgroup progress
2. Workgroup issues
3. Workgroup coordination
4. Documentation standard implementation
Please look at I:xxxxx with room for your progress.
Please take a note of the time you use for defining and documenting test cases. A system will soon be in place for automation of this registration, where we need the time already used now to be registered, please. Workgroups have now been decided and already slightly changed as shown above:
• XX from Back Office is now member of 9 covering Client Reporting
• YY from Finance is now member of 11 Financial Control
It is a key to our success in the program that all Workgroup Managers participate in called for 9:10 meetings, as these meetings in the early stage are used for ensuring that the Workgroups get started off in the right direction and approach their targets as fast as possible.
Because some project work has already been done in earlier workshops with focus on COTS functionality, it is now difficult to change this established culture—but we have to do that in order to reach our target of having the Core Banking Solution in production by November.
The current focus is BUSINESS PROCESSES END-TO-END.
This means that we do not try out business processes on the future core-banking information system solution until the COTS systems have been installed and adapted to these business processes.
The user Workgroups define business processes, test data, and business workflows to be tested in the future COTS-based information system environment:
• Business processes are described using the delivered documentation standard—quality to be established in practice.
• Test data are presented in screen dumps from the current information systems and the test cases representing all relevant variation are listed in Excel tables.
• Expected output can be a listing, a file dump, or a screen dump with reference to the test case giving this result.
Once a set of test cases representing a business process end-to-end has been created end approved by the complete Workgroup and your coach, it is delivered to the IT Workgroup.
The business process Workflow must, wherever possible, document required improvements to the current established business processes, especially where this concerns contractual or legal compliance.
The IT Workgroup (yet to be established) sets up COTS and other involved software to simulate the business process before the users are allowed to test the business case in the future environment. We will not waste the users’ time with endless demonstrations of COTS functionality, which they do not need. We only show what works for the bank users in real life.
If the COTS applications should not be able to improve the users’ current working conditions or solve the tasks required from the workflows, the problems are discussed in the 9:10 meetings and documented in an outstanding list for problem and change management.
In this context, we have already seen problems with the possibility to set up screen images corresponding to users’ needs and with reuse of codes and parameters from the current IT application environment, which indicates a potentially difficult future usage and learning process—not even mentioning conversion and integration problems.
See you 9:10!
Please send a deputy if you are not available. We will ensure that all Workgroup managers get together every morning just for a few minutes to discuss the progress and eventual issues.
3.12.3 Complications from Not Following Standard PQA
While the non-standard PQA result as such proved very efficient for the success of the Strategic Initiative implementation, it did not prevent all problems during the implementation of the COTS systems and the information systems using the COTS systems.
The manager of Finance was new in the organization and did not participate in the initial PQA Workgroup setup. Finance is more important in a banking environment than one might expect. All banking transactions are reflected in some financial transaction concerned with, for example, fees from clients and funds, where the bank is the selling agent, and with, for example, clearing costs from custodians and stock exchange agent services, and much more. Besides this, all human resources related costs including relationship management commission and normal business investments in IT and administration are handled by Finance.
Finance fully understood its central role during implementation and testing, but it caused many delays based on missing competence in the organization (the manager did not have banking competence).
The problems could have been avoided if Finance had made its role clear initially, but it refused to do that and demanded to implement the financial side of the solution on its own. It did not use the core-banking system for finance, only to feed the financial control COTS system that was procured as an additional requirement to the program scope.
In the mind of the Finance department, the implementation of the core-banking COTS system was responsible for explaining to it what transactions were fed to Finance without any responsibility on the Finance side.
The Finance arguments were strong and general management approved its requirement to be autonomous.
During the Accept-Testing situations, the contribution from Finance proved that this autonomy was a bad decision. Finance was never ready for testing because it did not have the time to understand the full financial implications of the bank transactions. Finance caused program delays of several months.
The bank risk manager was not involved in the initial PQA because he was occupied elsewhere. Unfortunately, we only learned about this ten minutes before the meeting started, so we could not send all other participants home. The risk manager refused to cooperate with program management or with any Workgroup in the program.
In the initial non-standard PQA meeting, the bank risk manager was appointed Workgroup leader because nobody else understood this very complex responsibility.
Risk Management expected to get all their required reporting from IT without presenting requirements other than copies of their current reports. The why and even the what and the how of these reports were not documented, so even the best programmer and report designer in IT could do nothing. On top of this, the old reports were completely outdated from a banking risk management standard view (Basel rules). General management again approved this situation and just expected IT to deliver.
For this reason, Risk Management was established as a Workgroup, but it never produced anything.
In order to improve on this situation, the program manager wrote an appropriate Activity Description for the Risk Manager, who did not like this at all.
SCOPE
Risk management is a core activity of banking. In the context of Core Banking, the Risk Management solution is implemented comprising:
• A documented and management signed off Risk Management Policy
• A set of documented and approved Risk Management procedures, which visibly comply with and fulfill the Risk Management Policy (the Bank Risk Management User Guide to be established)
• A set of documented tools in support of the Risk Management procedures (reports in and outside COTS, usage of and compliance with external and corporate information systems, etc.)
At a minimum, the currently implemented and documented risk policy and procedures must be reviewed and brought up to current Best Practice, for example, BASEL principles/standards (Basel states: “Clear strategies and oversight by the board of directors and senior management, a strong internal control culture [including, among other things, clear lines of responsibility and segregation of duties], effective internal reporting, and contingency planning are all crucial elements of an effective operational risk management framework for banks of any size and scope”).
DELIVERABLE
• An implemented agreed to Risk Management Policy for the bank that ensures organizational anchoring and ongoing improvement in accordance with best practice.
• Implemented agreed to Risk Management procedures.
• Tested, agreed, documented, and implemented COTS-based tools in support of the agreed to Risk Management procedures. This comprises the availability of a Bank Risk Management User Guide and Training with training material.
PURPOSE
The implemented Risk Management solution will provide the bank with documented best practice concerning the specific bank requirements for Operational Risk Management.
3.12.4 What We Could Have Done Better
One important success factor concerned with Activity Description preparation is that the Activity Leader (Sponsor) takes ownership of this description and the activity. In this way, the motivation of the sponsor is ensured and the people working to deliver the activity products get the best possible support in the form of knowledge and funding.
The lesson learned here is that only Activity Descriptions prepared by the persons directly responsible for getting the activity executed will be reliable, not the ones prepared by the Program Manager.
What I did here took away all opportunities to establish a feeling of ownership from the primary responsible Activity Manager, which I know very well is the key to success with any activity.
The program did close out successfully with serious delay because competent resources to close the holes in the organization were added later.
If I could redo this program, I would add a Program Office with competent resources to ensure appropriate requirements where the bank organization cannot provide these on their own. The Program Office could have the following resources:
• Business Analyst
• Banking Risk Expert
• Compliance Expert
• NAV Calculation Expert
• Finance and Tax Expert
• General Banking Operation Expert
• Reporting and Communication Expert also covering Program Performance Reporting
The Strategy Governance Team is a decision-making organization. They learn from Program Office findings and they have access to pertinent progress information prepared by the Program Office on the basis of tracking information from Workgroup managers and the Project Office. The Program Office works full time to establish pertinent requirements and to track specific program or Strategic Initiative progress.
The lack of a Program Office resulted in a too heavy work burden on the Program Manager and even on the Deputy Program manager and the other members of the Strategy Governance Team.
3.13 THE MILITARY HEALTHCARE INFORMATION SYSTEM CASE
The establishment of a Military Healthcare Management system is—as you would expect from a military-based case study—a PQA example of how PQA is done most efficiently.
We became responsible for conducting this project because we were well established in the Defense Facility Management, where we had implemented the common information system and produced all the handbooks and training material for the education and certification of Defense Facility managers.
The key-stakeholders here were not the facility managers, but the defense high command represented by doctors on a colonel level in cooperation with an army colonel responsible for the healthcare service information system implementation. The army colonel was our sponsor.
A group of military doctors and dentists (all of them military officers on a high level), the sponsor and his deputy, and a business analyst from my organization formed the Strategy Governance Team.
The sponsor and I developed the PQA Introduction for the Strategy Governance Team.
The Strategy Governance Team visualized and documented the complete project scope and established the Workgroups that developed the requirements specification.
As there was no prior experience with a common military healthcare information system, the requirements specification turned out to be a fully designed healthcare information system solution ready for programming or for implementation in a COTS application, if such one could be found.
PQA as a method was fully approved by all stakeholders for planning and project management.
There was absolutely no stress to provoke deviations from standards, and the result became excellent.
This case, just like the banking case, will also be used to show you the execution of business analysis and the preparation of core elements in the solution requirements spec, which will be shown in Chapter 5. Beside PQA facilitation, we also took on the role of business analyst and solution designer in this case.
3.13.1 Strategy Governance Team PQA Introduction
The Strategy Governance Team is also the team of people conducting the PQA Workshop.
The PQA Workshop Introduction (without the standard PQA process presentation) looked like this:
Implementation of an Information System for Defense Healthcare (DHS)
PQA INTRODUCTION (EXTRACT)
2. SCOPE AND INTRODUCTION
2.1 DHS AND THEIR CURRENT INFORMATION SYSTEMS
DHS core tasks are:
• Prevention and treatment of diseases in and injuries to military personnel. The preventive work is primarily focused on sports and work medicine. The treatment of diseases and injuries are primarily handled in the place of work infirmaries and dental clinics. In peacetime, the patient will be referred to the civilian healthcare system if the patient has a need for more complex treatments.
• To set up disaster and war preparedness, which during crises and war conditions allow the military to convene a large number of doctors and other healthcare professionals who have been trained in the military, and to establish field hospitals.
• Training of healthcare personnel, which takes place in schools and training units.
• Support to civilian authorities in the form of helicopter and sea rescue services, design of life-saving equipment at sea, etc.
DHS employs 125 people and has an annual budget of $45 million. To this must be added the permanent healthcare personnel at places of work consisting of approximately 300 physicians, nurses, dentists, clinic assistants, medical officers, medics, and others.
There are more than 50 infirmaries in defense distributed on the Army Operational Command, the Tactical Air Command, and the Navy Operational Command with operational ships.
DHS provides annually more than 200,000 medical consultations and more than 142,000 dental services.
In some places of work, it is possible to implement small-scale research projects in the form of drug testing, sports medicine studies, etc. DHS does not have a dedicated research program. The research projects are conducted as needed. The DHS annual budget for research amounts to approximately $10,000.
To support the execution of DHS tasks, the following healthcare information systems are currently used:
FMJS, the Pilot and Diver Medical Journal System WONCA, which registers all infirmary treatment with a WHO diagnosis code
FLOTRE, the Armed Forces Medical and Dental Healthcare Personnel register is not yet in use.
FMJS is today used solely in infirmaries under the Tactical Air Command. It only records the health status of the pilots even if the system is also prepared to be used for recording of the health status of divers.
FMJS manages healthcare information on all pilots. The main functions of FMJS are appointment-booking control for periodic medical examinations and administration of medical records. There are approximately 25 users of FMJS.
From a purely practical point of view, FMJS meets the information and management needs that exist in the area, but the technical platform for FMJS is quite outdated with a high derived risk of malfunction. The maintenance contract of the system has been terminated.
WONCA is used for recording of all inquiries to infirmaries in the form of a diagnosis (WONCA code). The used WONCA codes represent approximately 400 of the most common diagnoses out of the approximately 30,000 WHO diagnoses used in the civilian healthcare system.
Besides the WONCA code the patient’s name, social security number, and place of work are also recorded. These data are used for periodic reporting to DHS and external public healthcare organizations.
Both DHS and the places of work use data from WONCA in their establishment of objectives and activity frameworks.
At DHS, there is a presumption that the number of inquiries to the infirmaries is greater than the actual number of records in WONCA, which can be attributed to the current registration routines in the infirmaries.
Although it is now possible to register performed dental work in WONCA, this facility is not used in the dental clinics. The dental clinics use paper and pencil for their records and reporting.
FLOTRE is intended to be used to record more detailed data about the doctors’, dentists’, and nurses’ healthcare professional background (medical specialties, etc.). With this information recorded, it will be possible to account for the personnel’s current level of competence in connection with, for example, work placement under mobilization.
Master data in FLOTRE will be updated annually based on completed questionnaires from individual physicians, dentists, and nurses.
FLOTRE is currently not operational.
Apart from the above-mentioned information systems, locally purchased civilian electronic medical record systems are used in some infirmaries and dental clinics, which reflects the latent demand for such information systems. The problem with these COTS applications is that they most often rely on proprietary databases that in most cases do not provide possibilities for exchanging data with other external and internal systems.
The Workgroup on Medical Programming (WG Medpro) has produced a “Report on Electronic Health Recording Systems at DHS.” It confirms that the IT-based information systems used by DHS and the place of work infirmaries and dental clinics have not been implemented because of a predetermined data processing strategy, but rather ad hoc as the needs arose.
This has resulted in that the IT-based systems used are isolated “data islands” with no or very little value to the work processes and information needs within military healthcare.
2.2 WHY DHS NEEDS AN IT-BASED INFORMATION SYSTEM
DHS has called for the implementation of a common military healthcare information system (FOSIS) to replace all existing healthcare information systems that are used in places of work, thereby reducing the number of “manual” systems (especially the paper-based patient journals) and improving the quality of DHS services in general.
The primary objective is to implement an EPJ or Electronic Patient Journal. The EPJ must be standardized with a view to international usage to handle all patient data including ECG and X-ray images with a maximum of security.
The EPJ must be able to support the entire process associated with the treatment of patients in infirmaries and dental clinics, also in the context of mobilization (e.g., military field hospitals).
The EPJ must be able to operate geographically independent of the place of medical treatment so that patient data is not lost when such personnel are transferred to other places of work. The patient must have the opportunity to be treated in any infirmary or dental clinic with subsequent direct update of the patient’s EPJ.
2.3 WHAT WE WILL ACHIEVE IN THE PQA WORKSHOP
The purpose of this PQA Workshop in the DHS Strategy Governance team is to establish the project team and to define the framework for the implementation of FOSIS. The participants designated to form the Strategy Governance Team will define as detailed as possible why, what, and how concerning their requirements to FOSIS:
• The work situation and the results that they want to achieve with FOSIS
• The process that the project participants and future project participants must follow in order to implement FOSIS
• Current and future project participants’ involvement, motivation, skills, and competences
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 resources to be able to work effectively and produce efficient solutions, which can and will be accepted by DHS management and in the infirmaries and dental clinics. Relevant ideas and suggestions are however welcome.
2.4 HOW YOU PREPARE YOURSELF FOR THIS WORKSHOP
Your participation on the PQA Workshop allows you to express and demonstrate how you think the FOSIS project success can be ensured. You give inspiration to and get inspiration from the other PQA participants.
You must express:
• Your personal vision of the future FOSIS in DHS
Your interpretation of the mission of the FOSIS Project Governance Team
Based on your experience with and knowledge about your defense environment, please prepare an expression of what you consider the most extreme case of success for the procurement and implementation of FOSIS. Describe the factors especially relevant to your responsibilities and competences in your organization and within the FOSIS Project Governance Team. Please be prepared to explain your points of view.
The following areas of concern are examples of an inspiration to the subjects that we will consider under the workshop. Please remember to express why you intend to answer the question the way you do:
Who are the DHS clients?
What do the clients expect from DHS?
Can a common system solve the tasks for medical treatment and dental treatment?
What demands from the army are not relevant for navy and air force?
What demands from the navy are not relevant for army and air force?
What demands from the air force are not relevant for army and navy?
What are the areas of work where DHS can be more productive?
Who must participate in the definition of the detailed requirements to FOSIS?
Can DHS and the defense organization provide the competence required to succeed with FOSIS?
What external organizations and administrations must be involved during implementation?
Will we improve the administrative procedures in and under DHS before we implement FOSIS, or in parallel with implementing FOSIS?
Will DHS be an international organization under The Danish International Brigade?
What are the demands to the IT infrastructure in support of FOSIS? What DHS procedures must be supported by FOSIS?
Will DHS be certified ISO9000?
How can FOSIS improve the DHS Quality Management?
We look forward to a rewarding workshop. Kind regards
LI1 and LI2
3.13.2 Strategy Governance Team PQA Workshop Result
The PQA Workshop result looks like this:
DHS Implementation of
FOSIS
for
Defense Healthcare
Project Quality Assurance
Result
January
Participants |
||
Dent |
MW |
DHS (Project Manager) |
Mil |
AF |
DHS |
Dent |
MH |
DHS |
Doc |
OC |
DHS |
Doc |
KT |
KT |
Mil |
IB |
D IS (Sponsor) |
Off |
EH |
D ID |
Mil |
TN |
D IT |
Facilitation |
|
SL |
LI |
CH |
LI |
1 WHY DHS NEEDS ANIT-BASED INFORMATION SYSTEM
DHS has called for the implementation of a common military healthcare information system (FOSIS) to replace all existing healthcare information systems that are used in places of work, thereby reducing the number of “manual” systems (especially the paper-based patient journals) and improving the quality of DHS services in general.
The primary objective is to implement an EPJ or Electronic Patient Journal. The EPJ must be standardized with a view to international usage to handle all patient data including ECG and X-ray images with a maximum of security. The EPJ must be able to support the entire process associated with the treatment of patients in infirmaries and dental clinics in the context of mobilization (e.g., military hospitals).
The EPJ must be able to operate geographically independent of the place of medical treatment so that patient data is not lost when such personnel are transferred to another place of work. The patient must have the opportunity to be treated in any infirmary or dental clinic with subsequent direct update of the patient’s EPJ.
2 INDIVIDUAL VISIONS
OC
A system for the entire military healthcare, which:
• Meets the documentation requirements for examinations and treatments.
• Facilitates and streamlines workflows locally as well as exchange of information with the civilian healthcare system.
• Ensures access to information for relevant persons at all levels, thereby providing complete and reliable basis for the ongoing health-care advice.
• Ensures opportunity for statistical processing, etc. for use by the healthcare quality assurance and research locally as well as in the defense as a whole.
MH
FOSIS should be simple, easy to use, and be compliant with legislation for doctor’ and dentists’ work.
FOSIS data must be stored and secured, and thus at all times be available to relevant persons search on data.
FOSIS must be immediately compatible with civilian healthcare systems with flexible communications in mind.
Moreover, FOSIS must provide support in the daily work, including work organization, personnel management, and booking of patients.
FOSIS data must be recorded continuously, so that the management has updated information about:
• Production
• Consumption
• Waiting times
All of this is desired in order to be able to calculate the productivity/efficiency and capacity utilization.
KT
A single, approved registration system for all military healthcare services that meet any registration requirement:
• Manageable, clear, systematic sanitary professional documentation
• An effective management tool in the general and local planning
• Instrument to extract data in any ad hoc relationship (research, epidemiological and demographic data)
• Systematic exchange of information between management and users at all levels
• Quality assurance of healthcare services and of the healthcare organization
• Can communicate in the context of current and future communication facilities (fixed line and wireless communications) under both military and civilian conditions
MW
FOSIS must be a single system for all healthcare personnel in the Armed Forces, which is based on standards from the civilian healthcare sector, facilitating cooperation in the individual infirmaries and between the Forces. FOSIS should be able to solve the tasks everywhere.
FOSIS must meet the information needs with respect to the following:
• Daily patient care
• Electronic medical bag
• Decision support (Knowledge Couplers)
• Access to knowledge databases
• Operation support
• Patient Administration
• Planning
• Communication (internal/external)
• Management Information System
• Staff management
• Education
• Use
• Resource allocation
• Production
• Time usage
• Services
• Quality
• Data for research
AF
FOSIS must be a future-proof system (electronic system) to be able to accommodate all current healthcare systems in defense.
IB
1. Architecture
• Common system
• Operate on network and standalone
• Widely usable COTS
2. System Application
• Electronic medical bag
• Electronic journal
• Data extraction
• Update
• Support remote diagnostics
• DB
• Registration
• Reporting
• Statistics
• Diagnosis
• Replace existing systems (FMJS)
3. Management Information (MIS)
• Generate relevant KPI
• Support answering of questions from the political level
4. Communication
• Military and civilian networks
• In addition to alphanumeric data also imaging and X-ray image transmission
5. General
• Confidential P
• Used in garrison and under field conditions
EH
A user-friendly, mobile, and centralized paperless journal system appropriate to the defense IT strategy, including the integration with the De Mars management system:
• Intelligent study support
• The system must comply with all laws and safety requirements
• Exchanging information with external systems
TN
FOSIS must be a COTS product that is easy to work with, which meets DHS requirements, which can cooperate with other relevant defense systems, including the De Mars system, which must be well documented and easy to learn for users.
3. CRITICAL SUCCESS FACTORS AND THEIR SUGGESTED SUCCESS FACTORS
1. Essential FOSIS functionality implemented simultaneously on time.
1. The system is implemented simultaneously by all users.
2. The suggested solution must be accepted by DHS management before March 1.
5. Interdependent system components are implemented simultaneously.
10. The budget for FOSIS must be approved before March 1.
18. The tender must be completed by July 1.
25. The contract must be signed October.
32. The first phase of FOSIS must be implemented by the end of December.
47. FOSIS must able to be implemented in steps.
50. The annual maintenance fee for FOSIS may not exceed 15% of the purchase price.
54. Usage of FOSIS must be measured relative to well-defined milestones.
55. The future users of FOSIS must not lose their currently recorded electronic data.
2. Intuitive Danish language user interface.
3. Easy to use (user-friendly).
11. Fast to learn user functions.
12. The system should be easier, faster, and smarter to use than a paper-based system.
16. FOSIS must for each information user be able to present the necessary information in an understandable and clear manner.
57. FOSIS user interface must be in Danish.
3. FOSIS supports all healthcare services throughout.
4. The system must be able to support the healthcare services throughout.
21. Mobility without data reduction.
23. Procedures for full use of historical information.
26. FOSIS is able to provide operational support to:
• Patient Administration
• Planning and Resource Management
• Management of healthcare personnel
36. FOSIS must able to support DHS as well as medical and dental service in peace and the war structure under crisis and war (advice and workflows).
43. FOSIS must support the clinical decision process.
51. FOSIS must be a system common to medical and dental service in the Armed Forces.
52. FOSIS can be used down to echelon 2 level.
53. FOSIS must support centrally managed healthcare information, be it defined a priori or ad hoc.
58. FOSIS must replace all existing healthcare IT systems in defense.
59. FOSIS must be able to handle relevant healthcare management information.
61. FOSIS shall for each information user be able to present the necessary information at the right time and place.
4. FOSIS provides access to necessary and complete healthcare information.
7. The system must always be updated and contain all valid health-care information.
8. Consistent data.
31. FOSIS must be able to generate the necessary product reporting key figures.
33. FOSIS must be able to generate disease-and performance patterns for DHS.
37. FOSIS must eliminate the loss of all types of healthcare data.
41. FOSIS must ensure the validity and as complete data as possible.
55. The future users of FOSIS must not lose their currently recorded electronic data.
5. FOSIS communicates with relevant systems.
14. Well-defined interface to De Mars.
17. FOSIS must be able to communicate with civilian healthcare systems.
19. The system must be able to communicate among peers and with senior authorities.
24. FOSIS must be able to exchange data with the Conscription Agency’s IT-systems.
35. Data must be retrievable to be exported to analysis tools.
38. FOSIS must be able to receive data from the health cards, citizen cards, etc.
6. FOSIS meets the defense IT strategy and is based on relevant standards.
15. A flexible system that can be quickly adapted to changing requirements.
20. FOSIS must be based on civilian standards, such as SKS, EHCRA, HEP, and MEDCOM.
22. FOSIS must comply with the defense IT strategy.
29. FOSIS must be COTS.
40. Using standardized rules for journal record completion and reporting, FOSIS facilitates the access to epidemiological and demographic studies and research.
45. FOSIS must be a common system (uses the common technological infrastructure of the defense).
7. FOSIS meets all requirements for safety and traceability
9. Access to the data stratified.
30. There must be automatic logging of who has used the data when.
39. FOSIS must be acceptable safety wise by defense intelligence.
44. Full traceability of data in patient journal records and diagnoses.
62. FOSIS must for each information user be able to present the necessary information with high data quality and data security.
8. FOSIS enables a flexible, user-specific data handling.
23. Procedures for full use of historical information.
28. Clear longitudinal data presentation.
34. Optional chronological or problem-oriented journal.
40. Using standardized rules for journal record completion and reporting, FOSIS facilitates the access to epidemiological and demographic studies and research.
42. FOSIS must be able to handle hierarchical and self-selected workflows.
48. FOSIS must support a convenient, detailed, quantified activity registration.
49. FOSIS must be able to establish ad hoc defined arbitrary groups and action plans.
60. FOSIS is able to handle ad hoc definition and handling of data.
9. FOSIS increases quality and efficiency in healthcare service
6. The system must be paperless.
13. All healthcare service data must be contained in an electronic medium.
27. The introduction of FOSIS must be able to free up resources for solving of pt. not solved healthcare tasks.
46. FOSIS must serve to enhance the credibility of the defense medical and dental services for patients, Armed Forces top management, and civilian healthcare bodies.
56. User responsibilities and organizational structure supports an efficient use of FOSIS.
63. FOSIS must for each information user be able to present the information necessary at minimal cost relative to price and usage of time.
4. PQA MATRIX
3.13.3 Activity Description for FOSIS Implementation
These two Activity Descriptions were approved by the PQA Team to be executed immediately in support of procurement of the future COTS system that the team hoped to find. We were deeply involved with the Workgroups that performed the activities. As mentioned previously we performed business analysis and solution design to be used directly for tendering.
The tendering process would follow European Union standard rules. We were not at all allowed to be involved with the actual tender because we had been too involved with the production of the tender material production.
Here are the two Activity Descriptions:
Activity Description 3 |
Prepare Requirements Specification |
By: TN |
Approved by WG: January |
Scope |
Prepare a requirements specification (RS) for the Military Health Information System (FOSIS), which based on Project Quality Assurance (PQA) and Information Requirements Study (IRS) must describe all the requirements that users have to FOSIS. This RS is the basis for a future procurement. The main features of the IRS are: • Definition of functional areas • Definition of functional areas objects • Efficiency criteria • Documentation of communication needs • Requirements for new procedures and systems |
Products |
The RS, which describes the overall functional requirements for use of FOSIS at DHS and other authorities. Requirements for distribution of responsibilities and task solving in the organization to use FOSIS are documented in order to ensure optimal use of FOSIS. Furthermore, a cost/benefit analysis for FOSIS is documented. Finally, the overall requirements for FOSIS structure and functionality are documented with a suggestion of a phased implementation of the system. |
Purpose |
The preparation of the RS shall ensure that all stakeholders’ information needs in the performance of healthcare services are identified and documented, so these information needs can be related to the desired functionality in FOSIS to support the handling of the information needs. |
Responsible |
DIT |
Other resources |
DHS employees, WG FOSIS participants, DIS and DIT representatives, LI |
Sub-activities |
Task Description |
Resource Needs |
1 Clarify the analysis structure and define functional areas. |
DHS, WG, LI: 1 day |
|
2 Carry out analysis of necessary functional areas |
DHS, WG, LI: 40 MH per functional area |
|
3 Review of section reports on management level |
DHS, WG, LI: 24 MH per review |
|
4 Preparation of the requirements specifications |
DHS, WG, LI: 120 MH |
|
Time frame |
March to May Incl. |
|
Risks |
It can be difficult to release AG, DHS, NIV, the resources for this work, which could delay implementation. The necessary financial resources of Defense High Command are not allocated. Because of the desired FOSIS functionality, Defense Intelligence cannot approve further work. |
|
Dependency on other activities |
Predecessors: 2: Provide needs assessment Successors: 4: Prepare SSRS 5: Prepare tender documents |
|
Activity Description 5 |
Prepare Tender Documents |
By: TN |
Approved by WG: January |
Scope |
Prepare tender documents for FOSIS based on PQA, IRS, and RS. This must be taken into consideration for a supplier’s offer. The tender documents shall describe the requirements for a COTS product that takes DHS requirements in consideration. |
Products |
Tender documents with built-in ready to use contract “only” to be signed. |
Purpose |
To get a number of suppliers to offer the FOSIS solution based on the tender documents by delivering a COTS product, manage the implementation according to the implementation plan, and be responsible for the training of DHS and other authorities’ personnel in optimal use of the solution. |
Responsible |
DIT |
Other resources |
DHS employees, WG FOSIS participants, DIS and DIT representatives, LI, COTS vendors |
Sub-activities |
Task Description |
Resource Needs |
1 Logistics/schedule |
WG, DIS: 8 hours |
|
2 Legal conditions |
DIT, DIS: 4 hours |
|
3 Requirements to response content |
DIT, DIS: 4 hours |
|
4 List of vendors to be advised directly |
DIT, DIS, WG: 16 hours |
|
5 Demand to vendor quality system |
DIT: 4 timer |
|
6 Ready for use contract |
DIT: 8 timer |
|
Time frame |
June |
|
Risks |
It might be difficult to release WG, DHS, and Level I resources for this work, which could delay implementation. The necessary financial resources for the procurement of the COTS solution are not allocated, which might stall the project. Because of the desired FOSIS functionality, Defense Intelligence cannot approve further work. |
|
Dependency on other activities |
Predecessors: 3: Prepare requirements specification 4: Prepare SSRS Successors: 6: Complete procurement |
|
Risk Management performed efficiently can allow the teams involved with Strategic Initiatives to build plans that with higher probability achieve the solutions and results (the impact) demanded by the stakeholders.
We are constantly faced with pertinent unknown unknowns and unknown knowns that are ready to surface at any point in time in the future of our Strategic Initiative.
Risk responses are built into the project plan as improved activities or new activities to avoid the risk or to mitigate the negative effect of risk.
The Strategy Governance Team establishes and maintains the master plan that binds together and integrates all the subsequent plans. The Strategy Governance Team establishes the master plan as the top level PQA Team. In this top level PQA process, they establish the first level of subordinate PQA Teams that together ensure the delivery of the required strategically aligned solution components.
Active involvement of all pertinent and available knowledge from inside and outside of the organization in the PQA process ensures agreement to the established objectives for the Strategic Initiative. You need supplementary procedures and tools to PQA if you want to know where you are compared to where you want to be while executing a Strategic Initiative.
The needs of corporate stakeholders are very different, and most often inconsistent and contradictory.
PQA and other SQM processes such as outlined previously ensure completeness and sufficiency of the solution, the process, and the organization required to achieve the benefits expected from implementation of the strategy.
A Success Factor expresses a pertinent wanted and needed attribute of one or more quality objects, while a Critical Success Factor is a class of Success Factors.
The Strategy Governance Team knows and understands the conditions and the needs of the corporation in its current situation based on a thorough SWOT analysis or based on the mutual knowledge and experience of the team members.
PQA visualizes the motivating factors of the key-stakeholders by committing them to document and present their personal vision of the result of and their personal view on their mission during the Strategic Initiative.
The common acceptance of initial objectives and the initial strategy of activities to achieve these objectives ensure an opportunity for a “no conflict” implementation process.
The PQA rules have been established in order to ensure active involvement of all participants. No one is accepted just as a guest or to listen in passively. On the contrary, the rules are there to ensure the synergy that is only possible if the explicit and tacit knowledge of all participants are provoked to be used.
It is one of the keys to successful conduction of a Strategic Initiative that the top-level stakeholders and the original sponsors are involved and activated in the initiative activity whenever this gives them an opportunity to show their personal motivation and support of the PQA Teams.
All participants in the initial PQA Workshop participate in the first
PQA review in order to ensure that agreed activities are complete, valid, and consistent with regard to success of the Strategic Initiative. Think twice before you bring in new resources in order to speed up things—most often new resources bring more chaos than progress. If you need additional resources, make sure to plan for them and to allow for them to be competent and to be adapted to your activity. This applies to people and technology.
The Workgroup Team assists in the production of the Activity
Description to be reviewed by the PQA Team in order to ensure valid and reliable estimates and quality expectation.
If you do not have access to Project Office support, you are obliged to establish this support, even if you have to create your own Project Office. The Strategic Initiative planning workshops cannot yield a usable result without a fully up to date project management system database that is supported by the Project Office in support of the meeting discussions and decision making.
Only Activity Descriptions prepared by the persons directly responsible for getting the activity executed will be reliable, not the ones prepared by the Program Manager or the Facilitator.
The lack of a Program Office resulted in a too heavy work burden on the
Program Manager and even on the Deputy Program Manager and the other members of the Strategy Governance Team.