Team Building for a Strategic Initiative
A Strategic Initiative is taken because an organization or someone with enough power, the sponsor, has seen or been convinced about an opportunity worth going for or a threat that can be avoided or mitigated. This opportunity or threat is the initial cause behind a need for change to a better situation.
The initial challenge of the Strategic Initiative sponsor is to formulate the basic need and the initial scope, and to find the competent people that can and will be involved with this Strategic Initiative to make it successful.
Team building is concerned with the establishment of the best possible organization to perform the Strategic Initiative:
• Selection of people to become key-stakeholders in the Strategic Initiative
• Establishment of the teams of people and the roles and responsibilities of the people in the teams
• Definition of the roles and responsibilities of the teams to perform the tasks required during the lifecycle of the Strategic Initiative
• Establishment of the physical and technological environment within which the chosen people can act and communicate in an optimal way
• Establishment of standards to be used for processes, documentation, and deliverables in order to manage the quality of work, deliverables, and final solution delivered by the teams
Team building is a way to generate synergy; that is, the teams are organized in such a way that the performance of any team is higher than the performance measured as the sum of the team members’ individual performances.
The persons to be involved with the Strategic Initiative will contribute in different ways to the success of the initiative tasks:
• Initiate, approve, and govern the Strategic Initiative
• Implement the Strategic Initiative in the corporate strategy
• Coach and facilitate the Strategic Initiative activities
• Plan (develop) the Strategic Initiative
• Develop solution components
• Implement solution components
• Evaluate the Strategic Initiative quality
• Evaluate the Strategic Initiative performance
In order to ensure the best possible contribution to the Strategic Initiative from competent persons and teams, the sponsor provides them with the information, tools, techniques, environments, facilities, and whatever else that is needed to ensure their motivation and ability to perform well according to the “no excuse for failure” principle.
2.1 GET A STRATEGIC INITIATIVE OFF TO A GOOD START
Irrespective of what the Strategic Initiative is dealing with, which types and sizes of organizations are involved, what kind of people are available, etc. there is only one way to get the initiative off to a good start:
Get the key-stakeholders together and give them no excuse for failure to define the scope of the strategic initiative.
A key-stakeholder is someone with power, knowledge, experience, and competence within the context of the Strategic Initiative that you need to get involved in the initiative in order to make the initiative successful. It is a person who can create or sponsor the development and implementation of some part of the solutions you need. This part of the solution can be infrastructure such as land or public transport and institutions or it can be usage of new technology that can give you important benefits.
Other stakeholders are the classical ones that might benefit or suffer from the Strategic Initiative without being directly involved. You still need to make these stakeholders as happy as possible, which in some cases means “as little unhappy as possible.”
You use communication and remuneration to make stakeholders happy, but in order to make the communication and remuneration successful you need to know the stakeholders and their needs and expectations.
This simple stakeholder-based way to get the Strategic Initiative off to a good start poses some important questions to be answered before you can kick off the initiative:
• How do you identify the key-stakeholders?
• How do you communicate with the key-stakeholders?
• What is “no excuse for failure” in your Strategic Initiative?
• How do you get the key-stakeholders motivated for your Strategic Initiative?
• What is the scope of your Strategic Initiative?
There are no simple answers to these questions because the answers are hidden in the heads of quite a few people and some answers might only appear once you start asking questions to potential stakeholders and look into whatever experience material you can find.
I will show how I have handled these questions with some examples and let you judge the pertinence for yourself.
In all the examples, I have had the role as Coach/Facilitator for the Strategic Initiative sponsor; sometimes supported by other Coaches/Facilitators from my company or from other organizations. When I talk about “we” in the following examples, it means the Strategic Initiative sponsor and the Coach/Facilitator.
In rare cases, I have been faced with the problem of making some keystakeholders “as little unhappy as possible,” which also will be explained by examples for you to evaluate.
The sponsor initiates the Strategic Initiative and signs off on the scope as it is established originally and as it is adapted to new conditions and events during the lifecycle of the Strategic Initiative.
The sponsor establishes the Strategy Governance team.
In the case where a sponsor is a group of people such as shareholders or a public institution, such a sponsor is represented by a de facto sponsor role.
The de facto sponsor is a person who performs decisions on behalf of the original sponsor and who participates directly in planning and implementation on a high level, for example, on program management or the corporate management level.
The original sponsor might not exist as a person at all. Imagine a defense budget and a political decision to make the defense green with a part of the defense budget assigned to this objective. In this case, the sponsor is the government and the defense minister, but the government and the defense minister are not personally visible in the Strategic Initiative. However, a person has been made responsible for this task with a budget, and this person is the de facto sponsor.
For the purpose of Strategic Initiative treatment in this book, I will use the term “sponsor” for the de facto sponsor. If reference is made to the original sponsor organization, this is explicitly explained.
It is important to get to know the people with power and influence in the original sponsor organization. These people are key-stakeholders who are kept informed about the Strategic Initiative progress and who continually are motivated to support the initiative and the (de facto) sponsor.
The sponsor might be a CIO, a CEO, a CFO, or simply a program or a project manager appointed for the specific purpose of the Strategic Initiative.
The sponsor person might have more than one role in a Strategic Initiative.
2.1.2 The Coach/Facilitator Role
The Coach/Facilitator delivers the quality system and supports all directly involved team members and managers with appropriate guidelines, procedures, and documentation standards during the length of the Strategic Initiative.
The Coach/Facilitator role is most often delivered out of the corporate project office if this has been established.
The Coach/Facilitator ensures high-quality preparation and conduction of workshops, studies, and working conditions in support of teams to be established or already performing work.
The Coach/Facilitator has an important role to ensure the establishment of “no excuse for failure” teams.
The role that my company most often has delivered to our clients is the Coach/Facilitator role, especially in the case where the client wants to work according to a predefined set of methods.
In most cases, more than one person will take on the role of Coach/Facilitator during a Strategic Initiative because different organizational levels and objectives of teams or workgroups demand different knowledge, skill, and experience from their Coaches/Facilitators.
A Coach/Facilitator who coaches a general manager or a program manager will normally have a profile other than a Coach/Facilitator looking after an agile team of developers and implementers simply because the methods and standards used are very different and therefore demand different experience and knowledge from the Coach/Facilitators.
You can combine a group of Coaches/Facilitators in a Process Governance Team that supports one or more teams and workgroups under a Strategic Initiative.
In most cases, my company has employed competent external Coaches/Facilitators for our own Strategic Initiatives. When being external to the coached/facilitated organization, Coaches/Facilitators can contribute considerably to the value of the result of Strategic Initiatives because of their broader experience and because an external Coach/Facilitator has no constraints of thought and ideas based on former experience with the management of the coached/facilitated organization.
Before talking about how the Coach/Facilitator and the Sponsor can work together to identify key-stakeholders and to define the initial scope of the Strategic Initiative, I refer to a press conference with U.S. Secretary of Defense Donald Rumsfeld in NATO*, Brussels, June 6, 2002. Mr. Rumsfeld outlined the challenges faced in a complex defense situation, which could just as well be a Strategic Initiative situation:
Question from the audience: Regarding terrorism and weapons of mass destruction, you said something to the effect that the real situation is worse than the facts show. I wonder if you could tell us what is worse than is generally understood.
Rumsfeld: Sure. All of us in this (defense) business read intelligence information. And we read it daily and we think about it and it becomes, in our minds, essentially what exists. And that is wrong. It is not what exists.
I say that because I have had experiences where I have gone back and done a great deal of work and analysis on intelligence information and looked at important countries, target countries, looked at important subject matters with respect to those target countries and asked, probed deeper and deeper and kept probing until I found out what it is we knew, and when we learned it, and when it actually had existed.
And I found that, not to my surprise, but I think anytime you look at it that way what you find is that there are very important pieces of intelligence information that countries, that spend a lot of money, and a lot of time with a lot of wonderful people trying to learn more about what’s going on in the world, did not know some significant event for two years after it happened, for four years after it happened, for six years after it happened, in some cases 11 and 12 and 13 years after it happened.
Now what is the message there? The message is that there are no “knowns.” There are things we know that we know. There are known unknowns. That is to say, there are things that we now know we do not know. However, there are also unknown unknowns. There are things we do not know we do not know. So when we do the best we can and we pull all this information together, and we then say well that’s basically what we see as the situation, that is really only the known knowns and the known unknowns. And each year, we discover a few more of those unknown unknowns.
It sounds like a riddle. It is not a riddle. It is a very serious, important matter.
There is another way to phrase that and that is that the absence of evidence is not evidence of absence. It is basically saying the same thing in a different way. Simply because you do not have evidence that something exists does not mean that you have evidence that it does not exist. And yet almost always, when we make our threat assessments, when we look at the world, we end up basing it on the first two pieces of that puzzle, rather than all three.
Together with the key-stakeholders to be involved in the Strategic Initiative, we want to define the Strategic Initiative scope precisely:
• Why the Strategic Initiative is required
• The organizations to be involved and why
• Solutions and products to be delivered and why
• The needed quality of the solutions and product and why
We are faced with conditions that are not only the known ones. The Strategic Initiative conditions also comprise the unknown ones that we will meet in the future.
The current and future conditions present us with threats and opportunities that demand our response:
The known knowns |
These conditions have been documented in whatever requirements spec or problem list that has already been established. |
The known unknowns |
These conditions are known by stakeholders that have not yet been involved. It is the current pertinent tacit knowledge that you need to activate to understand more about your opportunities and threats. |
The unknown knowns |
These conditions should have been documented in requirements spec and problem lists, but these conditions are so obvious that no one thought about documenting them. |
The unknown unknowns |
These conditions you might discover as group synergy or by simple luck, but you will not find them if the minds of you and your stakeholders have not been set to be observant and creative—to “think out of the box.” |
2.1.4 Stakeholder Identification
Strategic Initiatives can have many different preconditions that will play an important role for the initial identification and selection of stakeholders:
• There might be a requirements specification that explains in detail what is expected from the Strategic Initiative.
• We might have signed a contract that explains in detail what is expected from the Strategic Initiative and what our roles are expected to be.
• There might be only a wish list established by the original sponsor who has only a vague idea about what is at stake in order to succeed with the initiative.
• There might be only a list of problems to be resolved and it is up to us to decide on our respective roles (Coach/Facilitator and Sponsor) and the roles of other key-stakeholders to be involved in the Strategic Initiative.
Once contracts, direct orders, or other agreements have ensured that the original sponsor supports the initiative, we start searching for the keystakeholders to participate in the future Strategy Governance Team.
Although the preconditions are important and we have to know and understand them, they are historical. Requirements specifications, wish lists, and even contracts are merely guidelines to get the initiative started off.
In most cases, you will find a first answer to why the Strategic Initiative is conducted in these preconditions, but sometimes even this important “why” is answered only with a political decision that in vague terms addresses the real opportunities of the Strategic Initiative.
It becomes a task of the chosen key-stakeholders and ourselves to answer the why question and the what and the when and the how questions as well of course in order to fully get to a common understanding and agreement about our opportunities and threats.
If we do not get the why right relatively early, we will have a hard time to motivate future key-stakeholders to get on board and to stay active in and motivated for the Strategic Initiative until the initiative closes out. Only if people feel that they contribute to something valuable can you keep them motivated. We keep this feeling alive by involving the stakeholders in Strategic Initiative processes where they can and will contribute positively and visibly to the result.
The Sponsor has knowledge about who the key-stakeholders might be and the Coach/Facilitator has knowledge and experience about how stakeholders can be treated and made happy, once identified.
To help us identify the key-stakeholders of the Strategic Initiative we establish the organogram with the organizational units to be involved (Figure 2.1)
We will also use the Value Chain to identify pertinent organization units and business processes for the Strategic Initiative (Figure 2.2).
FIGURE 2.1
Organogram.
FIGURE 2.2
Value chain (from http://bettyfeng.us) and strategy.
For each pertinent organization unit we outline their quality objects:
• Products
• What, how, and why they deliver what to or receive what from other organizational units externally and internally
• Quality, that is, why the clients like what they deliver
• What they produce in support of their own processes
• Key figures such as number of employees, annual production volume, cost of operation, etc.
• Processes
• What they do and why they do it
• Productivity measures
• Efficiency
• Organization
• Functional Areas
• Managers
• Clients internally and externally
• Key knowledge persons (skill, experience, competence)
• Communication and knowledge sharing
We discuss and document why each of these quality objects has an influence on or is the reason behind the known problems and objectives for the Strategic Initiative. We use this knowledge—and, quite often, the lack of knowledge on our part—to prepare ourselves for the initial dialogues with identified key-stakeholders.
Sometimes enterprise management or another original sponsor has already pointed out the key-stakeholders, but we still need to get to know their motivation for involvement in the Strategic Initiative.
We ask the key-stakeholders to tell us what they think the opportunities and threats are if we pursue the Strategic Initiative. We also ask them what they think the opportunities and threats are if we do not pursue the Strategic Initiative.
Finally, we ask questions that are more personal in order to measure their motivation for getting involved with the Strategic Initiative:
• What is your vision of the future situation when the Strategic Initiative has been successfully completed?
• What could your mission and role be in this Strategic Initiative if or when you get involved?
This initial dialogue with potential key-stakeholders who are potential participants in the Strategy Governance Team makes it possible for us to answer the why question with focus on real pertinent opportunities and threats. We obtain the information we need to prepare the Process Quality Assurance (PQA) to kick off the Strategic Initiative on corporate or strategy governance level.
You use the same type of dialogue to prepare PQA processes for other PQA Teams that are established on a lower level.
2.2 KEY-STAKEHOLDER SELECTION EXAMPLES
The examples shown have all been used to prepare PQA workshops or similar team building brainstorming workshops to kick off important Strategic Initiatives.
The first two examples comprise comprehensive changes to business processes required because the market and the client needs had changed with availability of new technological opportunities.
The third example is the private bank information system swap that was provoked by its technology being out of date. Contrary to the two former cases, this one has a demand for as little change as possible to business processes. It has to be proven that the new COTS application can at least handle the known business processes when it has been set up as required by the users.
2.2.1 A Merged ICT Consulting Enterprise Project Management Improvement
In this case, my company was called in as Coaches/Facilitators based on our long-time experience of program and project management of Information System implementation in international organizations.
The client had fully trained and certified program and project managers based on project experience in the Information and Communication Technology (ICT) industry, but also from implementation of SAP-based information system solutions.
SAP is an Enterprise Resource Planning COTS software package well known worldwide that can support business functions in any type of organization. The original application modules comprised Production Management, Inventory Management, Distribution Management, and Financial Management.
On the experience and competence level we were peers, but with very different and complementary backgrounds.
2.2.1.1 Initial Problems and Needs
The ICT and IT consulting firm is a merger of three organizations. This merger belongs to an international ICT consulting corporation with more than 30,000 employees. The local consulting firm runs numerous projects and smaller tasks to implement often-comprehensive client solutions and to implement their own Information System solutions based on SAP and other integrated software.
Project Management is a primary skill and competence of the ICT management consultants. In the various departments and functional areas there are different traditions for handling of projects and for registering the time spent on these.
It is essential that the time spent on all projects be recorded systematically and reliably, so that the experience can be used for future client offers and for improvement of the procedures used internally and externally. Some of the recorded time is used directly as a basis for billing of customers.
Registration of time spent must be coordinated so that the principles are the same from functional area to functional area, but without the specific requirements of each functional area being ignored. The different functional areas use specific Work Breakdown Structures with specific phases and milestones in support of their specific project planning and tracking needs that all must be supported by the new cross-organizational solution.
The Strategic Initiative must establish the basic requirements for future registration of time spent and develop an implementation plan, so this initial time registration can be started in April.
Since the time spent must be recorded in relation to projects, a very simple way to visualize the projects must also be conceived so that employees can record their time spent.
The Information System to be implemented will use a COTS application that includes the following needed functionality:
• Central repository of projects, resources, teams, user rights, and fundamental standards.
• Scheduler for the creation of projects, allocation of resources (from an assigned team) on tasks, and planning and follow-up on phases and activities.
• Time recording for employees to record time spent as resources on the created projects.
The project group’s (this was the Strategy Governance Team) initial objective and task is to establish the scope and the initial requirements for the future Project Management Information System that meets the requirements for time recording, which can be transferred to SAP when it has been checked and approved.
2.2.1.2 Sponsor and Strategy Governance Team Member Selection
The sponsor on this Strategic Initiative was the Project Support Office Manager. The project had attention from and the budget approved by the corporate HQ because the same need was recognized worldwide. The corporate HQ was the original sponsor.
The sponsor and I selected the team members among the following stakeholders:
Managers with long-time experience from conducting all types of ICT projects
Managers with experience from internal and external SAP projects
Project office managers to support the future solution implementation
Education manager to support the future solution implementation Finance
support manager in charge of internal accounting and invoicing of clients
The original sponsors (corporate stakeholders) were waiting for the result, but they were not directly involved.
After successful implementation of the new Project Management solution, my sponsor was promoted to implement the solution across Europe.
2.2.1.3 Strategy Governance Team Members
Network Integration Manager
Managed Service Manager
Enterprise System Integration Manager
Business Solutions Manager
Finance Manager
Finance Support (SAP)
Education Manager (internal education)
Education Manager (client education)
Project Support Office Manager (Sponsor)
Project Support Office PM Support
Project Support Office SAP Support
The team size of 11 people is not optimal (we regard 4 to 8 people as optimal) because too many ideas of marginal interest make the workshop take longer time to conduct without improving the result. You may reach a high number of participants in the Strategy Governance Team when many cross-organizational business procedure changes are required.
In this case, the Strategy Governance Team was big because the participants from different merged organizations needed to find a common playground for future Project Management, which would imply quite a few business process changes even in light of that part of the objective, which was to respect the individual behaviors and needs as much as possible.
2.2.2 Web Catalog Factory (WCAT) Order Management Improvement
In this case, my company was called in to develop and implement its future Project Management solution to be fully integrated with its Order and Production Management systems.
The case involves usage of the PQA procedure to establish motivation and involvement across all departments, which will be explained further under PQA examples.
Our own technicians and developers would work closely together with their own IT staff in order to develop the integrated solution and to prepare the education of the staff that would use the implemented information system solution.
2.2.2.1 Initial Problems and Needs
The company is one of the world’s most important suppliers of systems for production and maintenance of web-based catalogs to be reachable from many media. The catalogs can retrieve information across many databases and data media from alternative data providers.
Customers are typically large international companies with internationally distributed production and sale of their products.
Projects comprise internal development of standard systems and tailor-made customer solutions. Client solutions may be recurring orders involving only a few adjustments in each case, or they may be completely new orders with varying degrees of solution development.
Customer projects today require no great intensity in cooperation with the customer, but there is a tendency for it to become increasingly necessary to involve the client’s employees in system development, especially when it comes to more advanced user interfaces.
The wish for a new and better project environment must be seen as a natural progression toward greater efficiency and steadily improved competitiveness and customer service.
To improve efficiency, a better overview of production processes and their contexts is needed. Production process data must be collected systematically in a way that allows for preparation of standard times for standardized procedures. Production process data must show how cooperation between the various departments is handled during a project so that handover of partial deliveries can be ensured in time with the right quality.
It must be possible to assign available scarce resources across national borders.
It must be possible to prioritize projects, so that less critical projects do not inadvertently get critical resources assigned at a time when a more critical project requires their usage.
In order to increase competitiveness, besides through increased efficiency, it must be possible to analyze the impact on the production capacity of each customer order accurately in order to be able to build a realistic plan for cooperation with the customer on completion of a delivery.
The teams that are expected to complete a project must be shown as early as possible in the project database so that departments can plan their resource availability. The overview of resource capacity and the status of ongoing projects must be internationally available to sales and project management.
The future project information system must create visibility of active and planned projects so that the cooperation between project participants, project managers, and department managers can be handled on a realistic basis.
Acquired experience must be classified and available so that it can be used for future estimation and projects planning.
It is especially desirable that project participants can visualize that they have been good at planning their projects.
The Project Management Information System combined with improved business processes must ensure reliable and consistent information and communication in support of the daily project management and the long-term capacity planning of resources.
It is essential that the organization is prepared to exploit the system functionality effectively before the system is fully implemented. Many small victories are better than one “big bang.”
It is important that workflows around the system usage are in place and that there is education covering the concurrent usage of all integrated information systems for project management.
Finally, it is important that pertinent standards are established and implemented before the systems go into operation.
2.2.2.2 Sponsor and Strategy Governance Team Member Selection
My sponsor on this project was the General Manager. Besides getting the new information system in production as fast as possible, his primary objective was to establish broad motivation for the implementation of the future solution. It was therefore essential that all future types of users were represented in the Strategy Governance Team.
The following departments were identified to be involved:
• Administration
• Sales
• Client Support
• Planning
• Development
• Production
• Quality
• IT
2.2.2.3 Strategy Governance Team Members
The following were Strategy Governance Team Members:
General Manager
Deputy General Manager
Development Manager
Finance Manager
Sales Manager
Client Service Manager
Client Project Manager
Quality Manager
Production Manager
Deputy Production Manager
IT Development Manager
Lyngso coach/facilitator (Project Management Information System Development and User Education)
The Project Governance Team is rather big because a large number of business procedures will change, which needs involvement in decision-making across the whole organization. No single business function has the ultimate recipe for the future workflow.
2.2.3 Private Bank Information Systems Swap
In this case, I was contracted to be Coach/Facilitator for the Program Manager for a huge information system swap program involving:
• Swap of technology
• Swap of databases
• Complete workflow requirements documentation
• A big COTS back office application bought by top management yet to be set up and implemented
• Integration of a COTS-based reconciliation system
• Integration with a COTS-based fund management system
• Procurement and implementation of their future COTS-based finance solution
• Development of client and risk reporting
• Development of system integration
• Procurement of competent resources
Initially my title was Project Manager with direct report to the Program Manager. The initial objective was to get the program projects under control and to establish reliable progress tracking. In this respect, I was the Coach/Facilitator for the Program Manager, but that title was not recognized in the private bank organization.
2.2.3.1 Initial Problems and Needs
We have already seen some of the preconditions of this big program, but there are even more alarming reasons to perform immediate recovery:
• There was no Program Governance Team in place.
• The former IT Director had left the bank.
• Projects were only informally established without visible management.
• There were no requirements specifications.
• The current IT business system technology had to be swapped out quickly because it was without original vendor support (spare parts were only available from faced out equipment that was difficult to find).
• Project activities were performed by internal and external consultants in IT, the external ones invoicing monthly, but no one understands why the activities are performed, what the result is, and how the activities are performed.
• Training of busy future users had been initiated using the COTS application without adaptation to the users information system needs.
• The future users of the COTS application were very dissatisfied with what they saw during training and demonstrations.
• There was general frustration with the program progress, especially on the management level.
• A Program Manager had lost control.
• There was a new IT Director who did not like to see his budget spent on useless deliverables.
• There was no time to waste as the bank was faced with a risk of total IT breakdown every day.
I was not employed directly as the Coach/Facilitator for the IT Director initially; he only later became my Sponsor. My contract to be Project Manager with reference to the Program Manager was signed by the Program Manager.
The IT Director was new in the organization and he did not know anyone other than the Deputy General Manager who had signed his own contract. He was of course aware of the dissatisfaction and management frustration with the COTS implementation.
The COTS implementation Program Manager and the predecessor to the new IT Director had signed the contract that allowed external IT management consultants to send monthly invoices against the IT budget based on worked hours, not on results.
My first task was to get to know the Program Manager and to dig into what was happening in the program.
We quickly discovered that the external and internal consultants were doing GAP analysis. They evaluated all existing software functionality in order to establish whether it could be handled by the future COTS-based solution.
The internal and external IT management consultants involved with the GAP analysis rarely talked to the business users unless they had been involved directly with the former solution development.
There was no formal project plan and the documents from the GAP analysis were unusable because they just stated whether a solution could survive, never why or how it was accepted or refused.
Many future COTS application users had been given training in the COTS application that had not been adapted to their needs (yet). These needs were not documented. All users talked openly about their frustration to the new IT Director.
I presented these problems to the Program Manager, my contractual sponsor. As the Program Manager directly employed me, I was of course loyal to him and his decisions, so he was the first person to know about my observations that were of no surprise to him.
In full agreement with the new IT Director, we all agreed that we could not start criticizing the active program because:
• The program was initiated and backed up from top management level.
• Criticism this late would create more frustration in the program team, which was already under heavy pressure.
We decided that I would present myself and a recovery plan (“Suggested Improvements to the Project Plan”) to the current Program Manager and his managing team members.
The Program Team was established with:
• Primarily IT-based resources
• A few selected business operation staff with IT solution knowledge
• One COTS vendor representative
• The manager of the external management consultants
There was absolutely no finger pointing at anyone in my presentation. The presentation had no suggestions about enhanced management, only suggested changes to activities and objectives to speed up progress and get real results.
The Project Manager presentation meeting resulted in the following minutes that were distributed to the Program Management Team and the IT Director. The Program Manager and the IT Director informed general management and bank departmental management about the situation in a meeting. The Program Manager criticized me heavily in this meeting, to which I was not invited.
When you read the minutes you will understand the reaction from the Program Manager, and you will probably find a way to be more diplomatic yourself. However, it all depends on the situation you are facing, and in this case, there was absolutely no time to waste. What I did not know was that general management had already decided to replace the Program Manager.
Here are the minutes of my presentation to the Program Team that presented a way forward to be accepted by the IT Director (it was his budget) and the Program Manager (who agreed fully to the suggested project improvements):
The key to our success is that we can make the COTS application handle the Business Procedures that today are supported by outdated information systems running on non-supported technology and that we can build interfaces to several applications already active and currently interfaced with the outdated information systems. The delivered result must support all business functions ideally 100%, but realistically at least on a level where the banking operations are legally compliant.
We can succeed by simulating the real bank operations in parallel and interactively on the COTS application and on all other systems to be used in the future solution, which will demand and also ensure that the necessary communication between business competence areas of the bank and the bank’s IT side is established.
The target for this work is to establish an end-to-end test model, where we simulate all bank transactions with a variation ensuring that basically all possible business variance is tested.
This test model can be used again and again—also for testing of other applications; and it will be used during migration of systems and modules relating to the Core Banking Information System and the Corporate Risk Management Systems in order to verify that all system integration produce the required results.
The test model will focus on bank procedure functionality, not on COTS application functionality. The COTS application functionality will only be tested under Accept-Testing after it has been set up by experienced technicians to comply with the Banking Workflow requirements to be documented by banking user staff and departmental management.
To produce the business function test cases for our (acceptance) test model we need to reorganize the project organization into Workgroups with the following capabilities:
• Make necessary decisions
• Initiate required work
• Perform the work
• Evaluate the work done
Especially the capability to make and communicate decisions is important. This does not mean that all persons (roles) have to work together concurrently all the time, but it does mean that all roles and lines of communication are precisely defined before work is initiated in a Workgroup. 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 facilitate the communication between Workgroups.
Each Workgroup will have the responsibility to produce test cases (Workflows) of the production of specific (business) products (transactions, corporate actions, static data, reports, etc.) used either directly by bank clients or by other internal or external organizations/functions.
The consequences for the activities in current workshops are the following:
• Workshops will be used only for production of test cases (Workflows) to be used by the COTS system engineers for the setting up of supporting functionality in the COTS application.
• More than one Workgroup can participate in a workshop in order to ensure that all necessary knowledge and experience is used for production and evaluation of the produced test cases (validity, relevance, completeness, and consistency).
• The test cases are not developed in detail on the workshops—each individual Workgroup does the actual definition of test data within an agreed deadline.
• Each Workgroup participant will have access to use a current information system playground version for implementation, documentation of current Workflows, and for desktop-based verification of the results.
• Once the COTS application has been set up to accommodate a business function in its own playground IT environment, the relevant Workgroups will start producing training material to be used during Accept-Testing and later—after approval—for training of business end users and IT support.
The test cases will later on be used in formal Acceptance Test Sessions (workshops), when a test ready version of the COTS application has been set up by competent resources (not yet assigned to the program) to be Acceptance Tested.
In parallel with Workgroups producing business test cases, other Workgroups from IT operation, IT development, and IT infrastructure will be active:
• They prepare, operate, and maintain an agreed level of system service for current applications and later on the COTS application in a playground to be established.
• They set up the COTS application to be ready for bank user Accept-Testing and later on for user training and training of IT support personnel.
• They set up the COTS application and integrated information systems IT environment with backup, rollback, job creation, job execution, interface setup and timing, controlled operation, etc.
The idea is to generate a complete overview of and control with the capabilities of the COTS application-based Core Banking solution ready for Accept-Testing once all at this point known preconditions are met. We know that the COTS application quality will surprise us a lot during setup, e.g., the current list of problems and issues is already too long.
This primary target will be met by the end of June.
Between the end of June and until the end of September we will build (and simulated acceptance test) all the bits and pieces required for interfaces from current applications to the COTS application and for database conversion from the current information systems to the COTS application SQL database.
The objective is to replace the outdated information systems completely with the COTS application enhanced with functionality of interfaced known systems, and new information systems, e.g., the future finance solution to be established into the final new Core Banking solution.
All developed elements are documented:
• Test model
• Business processes
• User interfaces
• Jobs
• Interface solutions
• Data conversion rules and routines
• COTS application setup
• Reporting requirements and solutions
For each element it is declared why it has been done and why it has been made the way it is—hereby ensuring full traceability of issues and problems to simplify future maintenance, integration, and migration.
Project activities and decisions are documented with planned outcome, roles, responsibilities, and achieved results.
The project progress is documented in status reports with lists of outstanding issues. This work is handled under the heading of “Project Administration,” which will also look after project accounting and cost control.
All formal tests are documented with errors and issues logged from identification until final resolution.
The document standards are established and await agreement from the Core Banking Project organization (starts tomorrow).
All results will be documented immediately as outlined above (starts tomorrow).
This means that the work results achieved until today must be documented with the quality outlined above, if at all relevant (starts after the end of the current workshop).
All further workshops are rescheduled after today in order to allow for reorganization and completeness of Workgroups, i.e., expansion of the current user participation to be agreed with departmental management immediately.
Two days after this workshop, the Program Manager was replaced with me by general management (the original sponsor). I tried to warn my predecessor about the risk of this event, but the General Manager had already made this decision with immediate execution and without asking permission from the IT Director.
2.2.3.2 Sponsor and Strategy Governance Team Member Selection
As the former work had created more frustration than solutions and as no functional results, not even the COTS application in a technically accepted state, had been delivered, my new Sponsor, the IT Director, and I were ready for a new start, and so was the Program Team with their new Program Manager.
The first action performed by the IT Director backed up fully by General Management was to release all external management consultants. We only kept two technical consultants with COTS application expertise.
We then called a meeting where we invited two other key-stakeholders for the “new” program:
• The deputy General Manager
• My deputy Program Manager inherited from the former Program Manager
Before the meeting, I had used my research results to draw up my dream Program Management organization that would involve all business units including IT actively in Workgroups with agreed objectives and deliverables.
The suggested new Program Organization is shown in Figure 2.3.
The way that we ensured IT, Sub-contractor, and Vendor ownership of the technical solution components delivered to IT and Business Workgroups cannot be shown directly in the organogram.
FIGURE 2.3
Program organization example.
This ownership commitment was based on contractual conditions that were developed especially to this end. These contractual conditions are explained in Chapter 4 under Procurement.
The principles used to establish the new Program Management organization were:
• Establishment of the Strategy Governance team.
• Involvement of competent resources in organizational elements that get no excuse for failure, for example, the Program Manager ensures access to required document standards to be agreed by and used by all involved Workgroups. Many organization elements had no resources at all which was a problem and an opportunity at the same time because it allowed the new Strategy Governance Team to establish these elements in an optimal way.
• Business including IT ownership of all solution components to be delivered.
• Thorough quality management ensured by the Strategy Governance Team and directly managed by the Program Manger and his deputy. The deputy Program Manager had several years of experience from all business operations and could evaluate and challenge the quality of all Workgroup Workflow documents delivered for COTS application setup.
• Although some business function managers were more important than others were, it was clearly stated that Program Workgroup involvement respected only program specific management appointments. All Workgroup Managers reported to the Strategy Governance Team. Most of the Workgroup managers were also Business Organization managers with responsibility for the business processes treated by the Workgroups, which made it easier to ensure that the best possible resources got the necessary priority to perform the work with Workflow documentation.
PQA workshops were deemed unnecessary because only one key success factor was pertinent:
All business functionality must be compliantly supported by the new COTS application and other interfaced applications before the old technology breaks down.
To fulfill this success factor we had to execute all the activity in the project plans to be developed. The Strategy Governance Team possessed together all the knowledge, skill, experience, power, and competence necessary to establish the project plans with deliverables, solution components, organization, communication requirements, etc.
We replaced the PQA Workshop with a special Information Requirements Study (IRS) workshop, where all departmental managers and their deputy managers participated (20 people in all). In the IRS workshop we established all business process Workgroups and their scope of requirements specification Workflow production.
The project plans of course were fully documented and signed off by all pertinent managers for execution. All activities within the scope were fully documented and approved by the relevant Workgroup managers as if a PQA process had been performed.
The procurement of resources and integrated system solutions was an important part of the project plan that you normally only find in such big programs. The IT Director coached by me managed the procurement. My company delivered the concepts for requirements specifications and contractor contracts.
The final organization had more than 100 participants of which 50% were employed full time during the implementation of this Strategic Initiative that finally was run as a program.
2.2.3.3 Strategy Governance Team Members
The following were Strategy Governance Team Members:
Deputy General Manager
IT Director
Program Manger
Deputy Program Manager
The Strategy Governance Team was small because no cross-organizational business procedures were allowed to change unless absolutely necessary for legal or required business change purposes. If major procedural changes need implementation later, the Strategy Governance Team can be expanded.
In this context, completeness of the program with respect to projects and resources can be decided with support from the group of experts already known by the Strategy Governance Team.
A formal PQA process was not needed. The documentation that would have been established through the PQA processes still had to be produced in order to document the complete program plan and project plans that in the end delivered the required result. This documentation comprised detailed agreed upon requirements specifications for the deliverables from all Workgroups.
The deputy General Manger proved to be very efficient whenever conflicting interests surfaced between business operation, IT operation, and Program Management. Especially where business departments thought they could have just an advisory role, he was very convincing in his demand for direct involvement. On the other hand, we never succeeded to involve the finance department and the risk management department in a responsible way in the program. Both of these departments got general management support in running their own parallel projects, which created a lot of problems and delays, but did not prevent the program from succeeding in the end. Both of the managers from these departments later left the private bank.
2.3 ORGANIZATIONS FOR STRATEGIC INITIATIVE SUPPORT
The typical organization constructs involved with Strategic Initiatives from initial establishment to final implementation and governance are:
• A Project Office established in the line organization in support of all projects and programs in the corporation.
• A Program Office established as a secretarial function and an executive organization representing a Strategic Initiative Governance Team.
• Decision-making and executing teams established for the development and implementation of Strategic Initiative results under continuously changing conditions and risk.
Some generic types of organizations and teams are outlined next.
The Project Office is established on a corporate or enterprise level to support all teams that run projects in the corporate portfolio of projects, as well as the projects that belong to Strategic Initiatives or programs.
The Project Office has the role to support efficient communication among teams and between teams and corporate management and other stakeholders.
The Project Office governs the corporate methods, tools, and techniques used in the context of Project Management such as the corporate Project Management Information System.
This allows the Project Office to ensure valid and appropriate progress information from and to all teams and to and from the teams working under active programs and Strategic Initiatives.
The Project Office collects the planning and tracking information from all projects and ensures its completeness and value based on communication with all executing projects, as well as the projects established under programs.
This planning and tracking information is made available to all authorized persons.
Access to and distribution of planning and tracking information is also supported by the corporate Information Management System that contains and controls much more information than the project and program related one, for example, business performance measurement, financial information, client service information, etc.
The corporate Project Management Information System is normally integrated with the corporate Information Management System, but not always.
The Program Office is a secretarial facility and knowledge management center for a specific program.
It is composed of people with in-depth knowledge and experience from technical, legal, and political environments that are important knowledge areas for the program.
Based on this knowledge and experience, the Program Office can ensure that important information about rules, technological development, and political wishes is made available to the Program Governance Team.
The Program Office does not make decisions, but it prepares the information required for decision making by the Program Governance Team. In this respect, the Program Office can demand progress information from the Workgroups and the business organizations under the program.
Most often, the progress information requested by the Program Office has been prepared and validated technically by the Workgroup teams in question supported by the Project Office.
2.4 TEAM TYPES FOR STRATEGIC INITIATIVES
Our primary principle for establishment of teams is our agile principle:
The best solution architectures, requirements, and designs emerge from self-organizing teams. Self-organizing does not ensure this situation; it is the fact that the teams are established in such a way that self-organizing is possible that ensures the situation.
For efficient Strategic Initiative handling, we have used different team types:
• Some teams are more dedicated to establishing teams and providing the teams with “no excuse for failure.” They are good at defining scopes and setting targets. They are excellent at producing requirements specifications and setting up contract terms. They are excellent at communication with all types of stakeholders.
• Some teams are dedicated to producing and implementing solution components. They are good at responding to requirements and business Workflows with solution components. They have the skills and competences needed to select and utilize the best possible technology in the production of solution components.
• Some teams are dedicated to integration, Accept-Testing, and solution implementation. They are good at translating requirements specifications into business Workflows. They have business skills and competence that allow them to ensure legal compliance and secure operation and usage of integrated solution components. They can train and coach solution users.
The different types of teams have one set of capabilities in common (Figure 2.4).
We ensure that the teams can make decisions, initiate work, do the work, and evaluate the progress and the results obtained for process improvement, that is, perform their own quality management.
FIGURE 2.4
Team capabilities.
At regular intervals, the teams evaluate how to become more effective, then tune and adjust their behavior accordingly. The evaluation comprises communication between teams and with their environment of stakeholders.
This team capability to perform continuous quality improvement is ensured by:
• Dynamically providing the teams with resources that have the needed competences.
• Ensuring that an appropriate culture is in place for efficient communication.
• Ensuring that the required systems, tools, and technology are available to the team.
This is part of the “no excuse for failure” team principle.
Teams that miss some key competence might inadvertently have been established for two distinct reasons:
1. The scope of the work for the team is defined too large, which makes it impossible to combine the required skills and competencies within one team.
2. The team has been allowed to or been ordered to initiate work before all required skills and competences have been defined and allocated to the team.
In these cases, you will have to add time for coordination and communication across organizations or with external parties that might not have the same priorities or attitudes as your team. This adds duration, potential conflicts, bad results, and other negative effects for which you have to plan and to which you must respond.
By using appropriate PQA such as outlined in the introduction and discussed in detail in Chapter 3, these team-building problems and risks can be completely avoided.
In most Strategic Initiatives, you will work with more than one team, where each team is built according to the rule discussed previously. The cooperation between these teams is ensured with efficient communication and coordination managed by Program and Project Managers and supported by the Coach/Facilitators and the Project Office.
The interrelationship between and the mutual responsibility among the teams is documented in the agreed project plans, the program foundation, or in a contract.
Every time we have been faced with a new organization and a new corporate culture, we have had to rethink our approach to team responsibilities such as discussed in the different case histories, but the basic agile principles have always proven their value (Figure 2.5).
The different team constructs with which we have most often worked under Strategic Initiatives comprise:
• The Strategy Governance Team initiates a Strategic Initiative based on leadership decisions. The Strategy Governance Team ensures the successful conduct of the Strategic Initiative based on efficient communication. It is the top level of Change Management.
• The Process Governance Team coaches one or more PQA teams and is the second level of Change Management. Only Process Governance Teams can propose Strategic Initiative changes to the Strategy Governance Team.
• The PQA Teams lead, manage, and plan activity in order to deliver agreed tangible and measurable results. The Strategy Governance Team is a PQA Team concerned with initiation and kick-off of the Strategic Initiative and is concerned with major changes to the Strategic Initiative proposed by the Process Governance Teams. The PQA Teams can lead one or more subordinated PQA Teams and manage Workgroup Teams. The PQA Teams are the first level of change management. PQA Teams can suggest changes to the Process Governance Team that looks after the PQA Team.
FIGURE 2.5
Strateg y Governance Team structure.
• The Workgroup Teams perform production and implementation of agreed solution components. They control the quality of delivered solution components. They report progress in the Project Management Information System that has been implemented by the Project Office. Problems, Risk Conditions, and Events are reported to the PQA Team that manages the Workgroup Team.
2.4.1 The Strategy Governance Team
The group of people that establishes and governs a Strategic Initiative in the enterprise is called the Strategy Governance Team. The enterprise can be any type or combination of private, for profit, governmental, associative, or non-profit organization. The Strategy Governance Team can be from one person to many.
On a level decided by the Strategy Governance Team, it defines the complete set of solutions, processes, and organizations of the Strategic Initiative, that is, the detailed scope of the initiative.
The Strategy Governance Team has the power and the authority and under some constructs the full responsibility to lead the enterprise and to ensure that the enterprise is on track to achieve its agreed objectives.
Important Strategy Governance Team qualities include the following:
• Leadership—because this team establishes the original targets and objectives.
• Power—because this team sponsors the Strategic Initiative and makes the ultimate decisions concerning the direction and the budget of the Strategic Initiative work.
• Authority—because if the authority is not with this team, then subordinate process governance teams and even Workgroups will challenge decisions made and create unwanted conflict.
• Stakeholder Trust—because Workgroups and subordinate process governance teams must be able to work and progress with the certainty of the Strategy Governance Team backing and support; and because if some key-stakeholder loses confidence in the Strategy Governance Team, serious destructive conflicts will surface.
• Responsibility—because Workgroups and subordinate process governance teams will lose confidence and respect if management does not assume its responsibility, which leads to endless discussions and destructive conflicts.
• Empathy—because even the best formulated critique and demand for change must be investigated in light of personal attitudes among team members and key-stakeholders.
• Good coaching—because in order to be challenged to lead and to let other teams manage and work, good coaching is needed.
• Good facilitation—because in order to cater to good decision-making and team-building processes, facilitation is needed.
The Strategy Governance Team consists of managers with different functional backgrounds:
• Board Members
• Executive Management
• Technology and production
• IT and Information Systems
• Logistics
• Finance
• Client Relationship Management
The Strategy Governance Team leads, guides, or inspires other teams to destinations they would not go to alone by:
• Ensuring external efficiency
• Doing the right things
• Knowing why
• Managing people
• Establishing visions
• Finding opportunities
• Empowering people and teams
• Building the teams
• Having contacts
• Cooperating
The leadership role does not imply that managers of other teams cannot be members of the Strategy Governance Team. Leadership is not a personal matter but a matter of activating knowledge, experience, and motivation across a well-selected group of people with a common purpose.
The Strategy Governance Team establishes the Strategic Initiative based on a thorough SWOT (Strength, Weakness, Opportunity, Threat) analyses that if well done ensures that the why is answered for the initiative.
• The Strategy Governance Team evaluates the strength and the weaknesses of the enterprise in the market and the environment where it will operate; sometimes backed up by industry experts and analysts.
• The Strategy Governance Team evaluates the opportunities for doing business and the threats facing the enterprise doing this business. These threats and opportunities are the key to identification of possible strategic initiatives that can improve the situation of the enterprise.
The Strategy Governance Team has typically assigned my company to coach and facilitate Strategic Initiative implementation after that pertinence has been established with a SWOT analysis.
Only in rare cases have we met the industry experts and analysts employed by the Strategy Governance Team to do the SWOT analysis. These industry experts and analysts produce their own type of reports and give recommendations on the direction to take by corporate management, for example:
A major container line operator used a worldwide-recognized consultancy firm to evaluate the future development of the container line transportation industry and market. The container line operator was facing a need to invest in new capacity of three big carriers, a high-risk multibillion dollar investment, if they should continue to compete in the market.
The management consultancy firm would not recommend a continuation of the container line operator in the very competitive container market.
My company became the strategy implementation coach and facilitator based on continued container line business in this enterprise. We therefore took the container market continuation and the market knowledge of the major container line operator as a given. They were, at that point in time, one of the most important operators in the market.
Our Information Requirements Study analysis and recommendations were based on the business procedures and the needs of the container line clients and the other market operators in continued activity.
We recommended a Strategic Initiative that would improve the competitiveness of the container line.
Our recommended strategy would bring the container line operator in closer contact with the clients by using a floor-to-floor concept spiced up with cargo unit management that ensured that clients at any point in time knew the exact position and condition of their cargo.
This solution could vastly improve profitability and efficiency of the container line operator and the client logistics under given known market conditions.
However, the container line operator had a very weak management team, who listened more carefully to the fat words of the industry analysts than to the much more precise and less risky recommendations from their Coach/Facilitator.
Although all the employees and business managers were behind our strategic initiative to improve competitiveness, we could not convince the very defensive Strategy Governance Team to continue the container line business.
Looking back, this defensive decision was a very bad one. Another major container line operator has since used a concept similar to the one developed by the business managers and us with great success.
If the Strategy Governance Team comprises people with many different pertinent experiences and skills, there will be many different views on the business opportunities and threats. This multitude of views and experiences allows the team to establish a scope of the Strategic Initiative where threats and opportunities are well balanced in view of the strengths and weaknesses of the enterprise. However, the multitude of views and experiences also presents a risk of negative conflicts among the team members.
Once the Strategy Governance Team has established the initial scope of a Strategic Initiative, it establishes PQA Teams and Workgroup Teams to develop and implement the solution components of the Strategic Initiative. In this respect, the Strategy Governance Team is itself a PQA Team that produces PQA Teams or Workgroup Teams.
The Strategy Governance Team uses a PQA process to establish the underlying PQA Teams with their own scope and management.
The Strategy Governance Team does not interfere with the management of the PQA Teams and the Workgroup Teams once these have been established, if they deliver what is needed and agreed to.
The Strategy Governance Team establishes a Program Office to support the production of requirements specifications and to perform the ongoing support of the Process Governance Teams, the PQA Teams, and the Workgroup teams working to deliver the required solutions under the Strategic Initiative.
The Strategy Governance Team ensures the “no excuse for failure” conditions of the subordinate teams.
The Strategy Governance Team comprises or is the Change Control Board for the programs and projects under a Strategic Initiative.
The Strategy Governance Team will adapt the Strategic Initiative (govern the strategy) in response to unexpected events and conditions that cannot be coped with on a process and project management level in the PQA and Workgroup Teams supported by the Process Governance Team. Sometimes such changes are required because of changed conditions that were not accounted for in the initial SWOT analysis, for example, changes to corporate ownership, political trends, or corporate management.
Communication is the key to observing and understanding when new Strategic Initiative conditions require major changes to the Strategic Initiative. The communication in the Strategy Governance Team and among the Strategy Governance Team, the Process Governance Teams, the PQA Teams, the Workgroup Teams, the key-stakeholders such as enterprise owners, government, enterprise management, clients and partners, technology representatives, and subject matter experts needs management and methods that will be covered in subsequent chapters.
It is almost too popular to say that all the processes covered in this chapter and the subsequent chapters are communication processes, but it is actually the truth. The organizational constructs and interrelationships allow the communication to take place in an organized and effective way.
2.4.2 Strategy Governance Team Members
The Strategy Governance Team members establish and maintain the detailed scope of the Strategic Initiative from initiation to close out.
Strategy Governance Team members are people who together understand all aspects of the Strategic Initiative. The team members have been thoroughly selected based on their knowledge, skill, and experience and because it is expected that they are motivated for or at least interested in the scope and purpose of the Strategic Initiative.
The members of this team ensure that all known stakeholders are kept happy until final close out of the Strategic Initiative. The knowledge and experience of the team members ensure that together they can define the information and communication that is pertinent to the Strategic Initiative stakeholders of all kinds.
The sponsor has been appointed by the original sponsor based on an often vaguely defined scope and a budget to get the expected benefits realized.
This sponsor manages the Strategy Governance Team, that is, the sponsor handles, directs, motivates, or controls team members to deliver the objectives and to reach envisioned destinations by:
• Ensuring internal efficiency (budget, facilities)
• Doing things right
• Know how
• Managing activities
• Setting tangible targets
• Solving problems
• Having power
• Adapting to events and situations (managing change)
• Organization
• Assigning tasks to members
It is up to the sponsor and the other members of the Strategy Governance Team to ensure visibility and measurability of all accomplished results of the Strategic Initiative in order to ensure continued stakeholder support and budget availability.
2.4.3 The Process Quality Assurance Team
Process Quality Assurance (PQA) Teams are established by Governance Teams to make decisions about what to obtain and deliver, and about how to do it from the start of the Strategic Initiative and in connection with major changes or important milestones.
The PQA Teams lead, manage, and plan activity in order to deliver agreed tangible and measurable solutions to specific requirements.
Such solutions can be factory buildings, complete information systems, a new IT infrastructure organization, a new sales organization, a training program, legal compliance documentation, and many other more or less autonomous solution elements that together contribute to the benefits required from the Strategic Initiative.
The Strategy Governance Team is the top level PQA Team concerned with initiation and kick-off of the Strategic Initiative and is concerned with major changes to the Strategic Initiative as proposed by PQA Teams and Process Governance Teams.
PQA Teams are coached and facilitated by one or more Governance Team members or another competent person appointed by the Sponsor or the Process Governance Team.
The PQA Team can establish one or more subordinated PQA Teams and they appoint managers of Workgroup Teams if required. The managers of Workgroup Teams are most often members of the PQA Team. In the case where the PQA Team appoints a manager of a Workgroup Team, this Workgroup (Project) Manager becomes a member of the PQA Team.
The PQA Teams are the first level of change management. PQA Teams can suggest changes in scope based on new conditions, problems, or risks that they cannot cope with themselves. Such changes are suggested to the Process Governance Team that looks after the PQA Team.
The PQA Team exists only until the full scope under its responsibility has been established and signed off by the people that govern this scope.
Important PQA Team qualities comprise:
• Competence—they can outline the required result quality and design the organization that can accomplish what is needed.
• Knowledge—they cover skills and competence in the different subject matters such as potential market, competition, and technology.
• Experience—they have working experience from the required knowledge areas.
• Team members are complementary to each other, that is, with different backgrounds, attitudes, skills, and competences; if not, you get a biased solution missing important quality elements that might lead to failure of the Strategic Initiative.
• Responsibility—they must take ownership of the Strategic Initiative success factors, organization, and activity.
• Motivation—they drive the Strategic Initiative progress.
• Empathy—they cannot do it alone and they need to communicate in order to get to know and understand the motivating factors of all other important stakeholders.
• Authority—if somebody outside the PQA Team can impose changes not accepted by the PQA Team, then the whole idea of a self-managed team breaks down and the team members lose motivation.
• Good coaching and facilitation.
The Strategic Initiative scope has been defined and signed off by the Strategy Governance Team in terms of:
• Visions
• Objectives
• Quality objects
• Needs/deliverables
• Actions
• Organization
• Risk and other constraints
On this background, the assigned PQA Teams take full responsibility for the delivery of the agreed results, which implies that the PQA Teams are competent and autonomous (Figure 2.6).
The PQA Teams ensure the quality of the delivered solution components with respect to their compliance with the Strategic Initiative success factors.
The PQA Teams establish their own detailed success factors for their delivery of solution components and ensure sign off on their project plan by the Strategy Governance Team or the Process Governance Team looking after their project.
In order to ensure the best possible quality of the defined activities to be handled by the PQA Team, it is recommended that the future Workgroup managers “employed by” the PQA Team are involved as early as possible in the PQA Team, at best in the first PQA Workshop.
FIGURE 2.6
Team competence.
PQA team members are people that together understand all aspects of a solution to be delivered as part of the Strategic Initiative. I recommend the following qualities for PQA team members:
• Three years of middle or senior management position within the line organization or a similar experience and competence that might have been acquired elsewhere.
• Leadership attitude, if possible, that ensures a critical but positive attitude to the business environment and the organization.
• Well respected among peers and higher level managers.
• Empathy and patience as well as skill and experience of Subject Matter Experts (SME).
• Heroes are not welcome if they believe that they have to save the team.
• Original sponsors are welcome, but only in support of the Coach/ Facilitator and his or her sponsor.
• All participants are peers.
Their role is to manage projects and Workgroups that deliver partial solutions to a Strategic Initiative.
Members of PQA Teams handle, direct, motivate, and control resources to deliver objectives and reach agreed destinations by:
• Internal efficiency
• Doing things right
• Know how
• Managing activities
• Setting targets
• Solving problems
• Having power
• Adapting to situations
• Organization
• Assigning tasks
2.4.5 The Process Governance Team
The Process Governance Team is most often set up by one or more PQA Teams and approved by the Strategy Governance Team to be the second change management level in support of the PQA Teams. It ensures on behalf of the Strategy Governance Team that the PQA Teams it supports have “no excuse for failure.”
The Process Governance Team performs change management concerned with change requests originating from PQA Teams that cannot themselves cope with new conditions, incidents, observed problems, and risks reported by the Workgroups.
Only the Process Governance Team can request changes from the Strategy Governance Team.
The Process Governance Team exists until all the PQA and Workgroup teams under its governance have delivered their agreed results. The agreed results are what are delivered after all approved changes and adaptations to the original scope have been implemented.
Important Process Governance Team qualities comprise:
• Competence
• Knowledge
• Experience
• Stakeholder trust
• Strong relationship with Strategy Governance Team
• Team members are complementary to each other, that is, they have different backgrounds, attitudes, skills, and competences
• Responsibility
• Motivation
• Empathy
• Authority
• Coaching and facilitation
2.4.6 The Process Governance Team Members
Members in the Process Governance Team are most often also members of the Strategy Governance Team, but besides this they have a deeper interest in the deliverables and the functioning of the PQA Teams and Workgroup Teams they are supporting.
The Process Governance Team members have been thoroughly selected based on their knowledge, skill, and experience and it is expected that they are motivated to coach the PQA Teams and Workgroup Teams they are supporting, especially when it comes to handling of risk and problems.
The Workgroup Teams produce and deliver the solution components required by the PQA Team to which they refer.
The Workgroup Team delivers a tangible result at an agreed cost at an agreed deadline.
Workgroup Teams deliver their results according to precisely agreed Requirements Specifications that allow Accept-Testing and sign off on all results.
The Workgroup Teams are the foundation for the traditional agile principles. The agile demand of physical availability at the same time of critically involved resources for fast development with high quality results can be found in methods such as SCRUM, Xtreme Programming, and others.
It is of course not possible for team members to be together all the time, but it is important to plan the togetherness on specific occasions with important deliverables. Such deliverables are often called Use Stories or Sprints, which simply represent complete business processes with precisely defined input and output quality to be established by the business process.
Strategic Initiative development and implementation normally comprise much other activity and deliverables than software development and software. This implies that rather complex estimation, coordination, and tracking techniques are needed.
Planning and tracking continue to be agile because tracking and progress reporting are based on fully functional deliverables such as:
• Business requirements from Department X
• Workflow description of procedure Y
• COTS system setup of procedure Y
• IT infrastructure setup for security of W
• Intrusion detection ensured for the complete network
• Test models defined for procedure Y ensuring compliance with business requirement X
• Workgroup Z established and producing results as required
• Project plan for PQA Team Y agreed and signed off
The agile principles are pertinent for estimation and tracking. Progress is only measured by delivered solution components that through Accept-Testing have been approved and signed off to work in production.
The Workgroup Team is responsible for the delivery of a result of a certain quality that allows this result to be integrated with the deliverables from other Workgroups.
Workgroup Teams can be dedicated to quality assurance of integrated results from more than one Workgroup Team. Such QA Workgroup Teams have roles dedicated to Accept-Testing, result quality assurance and control, and process evaluation.
Workgroup performance is communicated to all other Workgroups, the PQA Team, the Process Governance Team looking after the PQA Team, and the Program Offices if relevant for tracking and change management.
Project Office project planning and tracking information systems support this communication. However, it is the responsibility of the Workgroup Team manager that this communication is reliable and efficient. The Project Office only ensures integrity and validity of the tracking information from a purely technical point of view, not at all from a project or program management point of view.
The Workgroup Team Members are skilled and competent resources most often managed by an informal manager or simply managing themselves under the support and coaching of one or more persons appointed by the PQA Team that has established the Workgroup.
The Workgroup Team Members are most often SMEs employed to deliver specific results. The roles always cover development, implementation, and quality assurance concerned with the functional and technical feasibility of their own deliverables.
For Workgroup Team Member roles, I recommend capabilities and qualities such as:
• Documented skill and experience in required subject matters and facilities
• Efficient production of code, solution documentation, software setup, software and solution integration, and solution delivery (to operation and implementation for use)
• Documentation of solution requirements, Accept-Testing, and solution implementation
• Solution and technology operation and support
• Security, compliance, and safety management
The Workgroup Team Members ensure the quality of the products delivered by them concerned with functionality, integrity, and fitness for integration and communication.
2.4.9 Cross Team Membership Value
The same person can be a member of more than one team and the same person can coach/facilitate more than one team.
A team can have more than one Coach/Facilitator in cases where the team objectives are very complex, for example, on the solution side, the technology side, the organization side, or the process side. In this case, SMEs can take the role of Coach/Facilitator. If your Strategic Initiative has a high risk of non-compliance for legal reasons, you might involve a Coach/Facilitator with close contact to legal bodies such as a lobbyist or somebody who is directly a member of the organization responsible for establishing your legal framework.
A Workgroup manager or at least one member of a Workgroup is most often also a member of a PQA Team. Some PQA Team members are also members of the Strategy Governance Team or another PQA Team.
The persons with cross team membership ensure a better interpretation of decisions, success factors, risks and opportunities, and needs across all teams. This ensures that changed conditions and not expected events that will occur all the time are observed faster and more reliably so that feedback to decision making and change management with suggested changes can be effectuated before it is too late to react.
2.5 THE NO EXCUSE FOR FAILURE PRINCIPLE
Once you have succeeded initially to identify the key-stakeholders in your Strategic Initiative, your challenges only begin because such keystakeholders with the needed competence are difficult to motivate and activate in your Strategic Initiative.
The best key-stakeholders are usually already allocated to or demanded to be involved in other Strategic Initiatives competing with your Strategic Initiative for resources.
The importance of these key-stakeholders in high demand needs to be confirmed in order for them to understand what benefits they can obtain from contributing to your Strategic Initiative.
Facing this stakeholder risk situation, your first response is to ensure that your Strategic Initiative complies with the “no excuse for failure principle”:
• You know why you need the key-stakeholder in your Strategic Initiative and you have a whole list of arguments that show the value for this key-stakeholder to contribute to your project.
• You know which internal and external activity that will compete for key-stakeholders with your Strategic Initiative and you respect their importance as well.
• Because you are involving people with very different skills, experiences, and competences, you know that conflicting interests are inevitable. You have organizational elements and procedures in place to avoid conflicts becoming personal with a negative impact on the Strategic Initiative progress.
• By using professional coaching and facilitation, you ensure that conflicts only result in lateral thinking (out of the box) and synergy on workshops and during other types of teamwork.
• At any point in time, teams and key-stakeholders have access to all needed and available resources and knowledge constrained only by accepted limits to their availability.
• You plan to ensure that all required resources to be involved in an activity are available and allocated to the activity before the activity is initiated with assignment of these resources.
• You do not initiate an activity if you know that any required resource is not available to be assigned to the activity.
You incur important risk by not complying with the “no excuse for failure” principle:
• Biased strategy focus because important knowledge or competence that is left out initially might lead to development and implementation of solutions that do not comply with stakeholder needs—you will lose capital and time.
• Key-stakeholders might lose confidence in the Strategic Initiative because the not involved but required resources raise pertinent critiques of the chosen initiative scope and objectives—you will lose time and key-stakeholders might leave the initiative.
• If the involved resources do not have the competence to reach a conclusion about critical success factors and the way forward to an agreed solution, then the key-stakeholders waste time and lose confidence in (your) management.
• Important processes might be performed with interruptions because of lack of important resources, which leads to waste of time and bad results.
• The initial enthusiasm of the key-stakeholders can disappear very fast if you do not keep them motivated by immediately involving them in pertinent strategic initiative activity, where they get a chance not only to prove their competences, but also to use this competency directly in cooperation with peer stakeholders.
• If the key-stakeholders lose interest in your Strategic Initiative, then the initiative might already have failed.
• If the key-stakeholders get into negative conflict with you or with each other while conducting the Strategic Initiative activity, then the initiative is probably already doomed to fail.
• If some resources accuse other resources of failure, it creates stress and negative conflicts that are the reason for delays that could have been avoided by better selection of resources, better team building, and better working conditions.
Unfortunately, the “no excuse for failure” principle is not all you need to comply with in order to succeed, but if you do not comply with it, you will challenge yourself and the key-stakeholders with unnecessary problems and issues that might in the end make the initiative a fiasco.
The initial dialogue processes and the continued communication with key-stakeholders require serious preparation and very good coaching and facilitation, especially if you are new to such dialogues and communication.
There are more examples of failed Strategic Initiatives than of successful ones—even in major organizations that should have access to the needed and required resources such as Digital, Nokia, Sony, and Philips.
The War Room is a construct that I recommend to establish even for teams working geographically separated over very long distances in different time zones (Figure 2.7).
FIGURE 2.7
War room from Americon in Camarillo, California.
The War Room contains all pertinent tools, information, and documentation in support of a specific team with all the technology available to access and manipulate this.
The term “War Room” originates from military combat management. It is the environment where involved officers meet to discuss experience from already executed activity and to make decisions about the activity to perform before the next War Room meeting. In combat, the officers meet very early every morning.
In the case of civil strategic initiatives, the War Room serves the same purpose, but the meetings might happen less often than daily.
I have established War Rooms to be used for Strategic Initiative activity covering decision making, workshops, teamwork, and other events where it is essential that all resources are available in order to ensure the best possible decisions.
I have also established a simple War Room in support of Help Desk activity, where the Help Desk teams met each morning to discuss the support events since the last meeting and to decide on the actions to perform:
• Events to be treated as a project by other organizations
• Events to be resolved immediately by the Help Desk service team
• Open events not yet responded to
• Recurring events demanding future preventive action
Until a team has delivered its result as agreed with the involved stakeholders, the team meets at regular intervals in the War Room to make decisions and to kick off the work processes performed by or governed by the team.
The Workgroup Teams that produce physical solution components can fully benefit from daily War Room meetings. Where I have managed such Workgroups, we have always met in the War Room at 8:30 every day over donuts and coffee to present achieved results and to discuss unexpected or risk managed events and conditions demanding actions to be taken by the team or management.
War Room meetings are never a waste of time, even if you just verify that everything is progressing in good order and with the results as expected, which is of course rarely the case.
When the result or an important milestone has been reached, the War Room is also the place to have champagne and plan communication with other stakeholders.
The War Room is easy to protect physically from unwanted intrusion with cameras and electronic and physical access control. Furthermore, it is easy to build IT firewalls around the work environment of tools, documentation, minutes, and solution components under version control.
There is no physical limit to a War Room. I have had War Rooms as small as the office manager’s desktop to a set of interrelated containers with more than 500 m2 of space, more than 100 PC workstations, and a combined Workgroup Team with more than 50 people. Only partial teams met every day at 8:30, but they did, and I had no problem getting in contact with my active Workgroup Teams.
2.6.1 The Private Bank Solution Swap War Room (Figure 2.8)
It was impossible to know if the active IT solution could survive more than 12 months, where the 12-month survival could be ensured only by investing in very expensive backup equipment to be thrown away once the new solution became operational.
• The teams in place had to be completely reorganized.
• No competent contractors had been contracted.
• There was no requirements specification because the organization management was convinced that the bought system could provide a solution on its own.
FIGURE 2.8
Container office War Room.
In order to cope with all of these problems at the same time, we decided to integrate all future teams under the same roof while ensuring that all required knowledge and skill was available as needed any time we were in this War Room.
The War Room decision was an agile one, but everyone thought it would be prohibitively expensive because the organization had no “agile” experience.
The negative voices were overruled and the agility was ensured with a comprehensive War Room built with containers backed up with new efficient processes, teams, and documents comprising:
• An initial requirements specification
• New creative contract terms approved by the legal department on concern level
• Contracted needed internal and external skill and competence
• System software and IT operation was established for development, test, and training
• Program and project plans were signed off
• All resources, human and technical, were brought together under the War Room roof
• Security and safety systems and routines were established to protect people and solution components
Only final solution components that had been Accept-Tested to be ready for use were allowed to leave the War Room for business operation.
All work and all intermediate results never left the teams in the War Room.
This team building with War Room resulted in a very successful solution delivery with very motivated team members from inside the bank and from the contractors. Agility was clearly manifested in the work performed (teams of developers, business analysts, and future Information System and IT support and users working closely together) and by the progress tracking that was based on delivered solution components.
Team support for “no excuse for failure” rather than team progress control ensured the fastest possible progress and delivery of fully Accept-Tested solution components.
In the end, the total cost was only half of what a turnkey contractor had offered at the outset.
The alternative contractor offer had been made under the condition that the bank accepted the integrity and full responsibility of the contractor, that is, the contractor decided what the bank needed, which fortunately was not acceptable to the bank director. Just for the record, the bank was willing to pay for this “safe” solution, but it did not want (one more time) to be kept in the dark until a final solution was in place—or failed to be.
2.7 SPONSOR AND KEY-STAKEHOLDER RISK
The Strategic Initiative original sponsor can be a group or a public budget controlled by a selected group of people, often politically selected or appointed by shareholders or other business owners.
Quite often, it is not even obvious who the original sponsor is.
This implies that you and your sponsor without knowing why can be met with fast changing conditions for the Strategic Initiative up to a level where this initiative for some more or less obvious reason is cancelled.
The opposite, for example, changed delivery conditions with more or less time to deliver and improved resources and budget opportunities, is of course also possible.
You are obliged to work “hand in hand” with your sponsor to cope with this original sponsor and core stakeholder risk:
• If you are facing a weak sponsor, you strengthen this sponsor’s capability to communicate with your key-stakeholders. This is one of the most important roles of a Coach/Facilitator.
• If you are faced with a strong sponsor, you gain his or her respect and trust in order to make sure that you as coach and facilitator are informed and are asked for advice—even though your sponsor thinks that he or she can act and decide without consulting you.
In my work with major international consultancy organizations and major vendors of software, their top or sales management and sometimes their own smart Coach/Facilitators have quite often tried to establish a direct communication with the original sponsor’s core stakeholders (the ones with the budget authority) once these have been identified.
In this way, they bypass the sponsor and his or her Coach/Facilitator. In some cases, they unfortunately enough succeed in getting decisions through that are contradictory to the progress of the Strategic Initiative that they are supposed to support.
The objective of bypassing the sponsor in this way is always to bring in more resources and more product before the Strategic Initiative has come off to a good start or even in the middle of critical development and implementation activity, where the original sponsor is most vulnerable because the first problems, delays, and cost overruns have been reported.
Based on their communication and observations outside the control of your sponsor and you, the original sponsor key-stakeholders might suddenly behave in ways that are detrimental to the foundation of the Strategic Initiative. They express new opinions and attitudes that you do not recognize, but that you need to respond to.
The original sponsors’ and other important stakeholders’ attitudes and opinions represent risk to the Strategic Initiative that you and your sponsor need to respond to from day one.
One way that you can prevent these quite often catastrophic changes to the Strategic Initiative foundation is by always trying to strengthen your sponsors’ ability to communicate in his or her environment of original sponsors, peers, managers, and key-stakeholders.
Person-to-person communication—certainly not by e-mail or telephone—is the best response to sponsor and other stakeholder risk. Such person-to-person communication is not easy to obtain for some important reasons:
• You might not know the person to talk to.
• The person to talk to might not be committed to talk to or listen to you or he or she is too busy to meet with you. (Typical response when you ask for a meeting: “Send me an e-mail with your arguments.”)
• The communication is prepared with proofs and arguments that ensure that the original sponsor has trust in you more than in other relationships when it comes to your Strategic Initiative, which is difficult if you do not know the attitude of this original sponsor person.
You cannot win here if you do not have an established relationship with the original sponsor who commits to listening to you and talking with you, a relationship that is established as part of the Strategic Initiative kick off.
The following is an example of a strong (public) sponsor:
While working as Coach/Facilitator in the military facility management program, my sponsor was a very apt officer on the commander level from the navy side.
He knew everyone in high command and he was a vital member of very important non-professional networks.
This sponsor had complete trust in our methods because he had seen them work in another big project, where he was Project Manager.
He trusted the involved resources from my company (still does) and he was able to select the most competent defense resources across army, navy, and air force representing both facility managers and facility users.
He was able to warn us whenever there was a risk of conflict with other interests or projects.
With his intervention, we got access to all the right levels of decision-making and knowledge during the length of the project. Moreover, he ensured that we could present achieved results of more strategic impact on important pertinent conferences and meetings, which allowed us to ensure satisfactory budgets for our required work. Our response was, of course, reliable statistics, delivered results, and happy stakeholders.
The way he appointed people for our workshops and teams on all levels and the way he helped to ensure efficient communication resulted in the success of the teams and in the success of the whole program.
When after 5 years of successful conduct and cooperation our sponsor was replaced with a new one, we got serious trouble because the new sponsor did not at all see my civil company as his future Coach/Facilitator.
Quite often, you will be faced with a de facto sponsor that has limited knowledge and experience from the organizations to be involved with the Strategic Initiative. This is more an opportunity than a threat.
Very experienced and competent sponsors might be less good for the Strategic Initiative than the less experienced but also very competent sponsors might be:
• A sponsor who knows everybody is a bit dangerous if he or she has many prejudices and “friends” that he or she wants to be involved in the Strategic Initiative. If this preferred group does not represent the best available knowledge and experience, you will have a hard time to get the right people “on board.” The risk is that your sponsor looses a lot of money before you get him or her on the right track. There is a limit to how you as a coach/facilitator can manipulate your sponsor to do it right the first time because your sponsor does not and will not tell you everything about what he or she knows, and especially not about what he or she knows that he or she does not know.
• A sponsor who initially knows only a few people will be willing to listen to your advice to a much higher degree. He or she will probably use the Strategic Initiative to get to know people. With such an open-minded de facto sponsor, you and the sponsor need to establish initial dialogues with people that you expect will play major roles in the Strategic Initiative. Through these dialogues you gain an opportunity to evaluate the possible participants in the Strategy Governance team with respect to their knowledge, experience, competence, and motivation. This will make it possible to get the best teams in place early and thereby mitigate the risk of delays and loss of money, and it will contribute to a closer relationship between you and your sponsor.
The initial challenge of the strategic initiative sponsor is to formulate the basic need, the initial scope, and to find the competent people that can and will be involved with this strategic initiative to make it successful.
Irrespective of what the strategic initiative is dealing with, which types and sizes of organizations are involved, what kind of people are available, etc. there is only one way to get the initiative off to a good start:
Get the key-stakeholders together and give them no excuse for failure to define the scope of the strategic initiative.
You use communication and remuneration to make stakeholders happy, but in order to make the communication and remuneration successful you need to know the stakeholders and their needs and expectations.
The sponsor initiates the strategic initiative and signs off on the scope as this is established originally and as it is adapted to new conditions and events during the lifecycle of the strategic initiative.
The Coach/Facilitator delivers the quality system and supports all directly involved team members and managers with appropriate guidelines, procedures, and documentation standards during the length of the strategic initiative.
The unknown unknowns are the conditions that you might discover as group synergy or by simple luck, but you will not find them if the minds of you and your stakeholders have not been set to be observant and creative—to “think out of the box.”
Although the preconditions are important and we have to know and understand them, they are historical. Requirements specifications, wish lists, and even contracts are merely guidelines to get the initiative started off.
This initial dialogue with potential key-stakeholders who are potential participants in the Strategy Governance team makes it possible for us to answer the why question with focus on real pertinent opportunities and threats.
The Project Offices support all teams that run projects in the corporate portfolio of projects, as well as the projects that belong to Strategic Initiatives or programs.
The Program Office is a secretarial facility and knowledge management center for a specific program or Strategic Initiative.
The best solution architectures, requirements, and designs emerge from self-organizing teams. Self-organizing does not ensure this situation; it is the fact that the teams are established in such a way that self-organizing is possible to ensure the situation.
Once the Strategy Governance team has established the initial scope of a Strategic Initiative, it establishes PQA Teams and Workgroup Teams to develop and implement the solution components of the strategic initiative.
The Strategy Governance team establishes a Program Office to support the production of requirements specifications and to perform the ongoing support of the Process Governance teams, the PQA teams, and the Workgroup teams working to deliver the required solutions under the Strategic Initiative.
Communication is the key to observe and understand when new Strategic
Initiative conditions require major changes to the Strategic Initiative. PQA teams make decisions about what to obtain and deliver, and about how to do it from the start of the strategic initiative and in connection with major changes or important milestones.
The Process Governance team is most often set up by one or more PQA teams and approved by the Strategy Governance team to be the second change management level in support of the PQA teams.
The Workgroup teams produce and deliver the solution components required by the PQA team to which they refer.
The initial dialogue processes and the continued communication with key-stakeholders require serious preparation and very good coaching and facilitation.
The War Room contains all pertinent tools, information, and documentation in support of a specific team with all the technology available to access and manipulate this.
The original sponsors’ and other important stakeholders’ attitudes and opinions represent risk to the strategic initiative that you and your sponsor need to respond to from day one.
* Donald Rumsfeld press conference, June 6, 2002. http://www.nato.int/docu/speech/2002/s020606g.htm (With permission of NATO).