ITMPI FLAT 002
Main Menu
Home / CIO / Agile Strategy Management Lessons Learned

Agile Strategy Management Lessons Learned

Abstract

The paper presents practical experience with agile strategy management methods and techniques gathered from multiple missions in private and public enterprises.

People and communication are in focus. These elements present at the same time the foundation and primary opportunity for success, and the biggest risk of failure.

The experience shows how weakly established organization structures and objectives make communication and people enter into conflict instead of working together to reach feasible and beneficial business results.

Without going into detail with method and HOW descriptions the paper outlines through case stories a set of tools that have been used for stakeholder management, for team-building, and to bring organizations in crisis back on track.

The same framework of tools used early in and throughout important strategic initiatives has been used to achieve beneficial business results fast without any conflict using the “no excuse for failure” principle.

The conclusion is that all stakeholders must be known and treated in such a way that they are happy from initiation to close out of a strategic initiative. The involved stakeholders need visibly planned for and agreed to organization structures, methods framework, object definitions, and communication to be successful and agile.

1 Why Agile Methods

Agility is about people. People formulate wishes and requirements. People form teams and organizations for communication. People implement and develop solutions. People ensure the quality of delivered solutions. People change their minds and adapt the wishes and requirements accordingly.

But people also enter into conflict and disagreement that can be counterproductive in critically important strategic initiatives. The agile methods presented here were used to deliver strategically aligned Information Systems in complex organizations. Standardized dialogues with all pertinent stakeholders in the context of fully standardized processes allow for a good initial scope establishment:

  • Stakeholder identification and involvement
  • Business analysis
  • Complete scope definition using critical success factors
  • Object-oriented solution design

The dialogues take place in scenarios that ensure motivation and best possible contribution from all involved stakeholders to such a degree that these stakeholders want to take ownership of the result—collectively and without conflict.

As facilitator and coach you add value to the client solution by delivering tools, techniques, and solution components that you happen to have the competence to deliver. The final solution and the knowledge transferred or shared belong to the client. The methods and techniques are used successfully in industries such as these:

  • Finance (Bank and Insurance)
  • Pharmaceutical Production
  • Health Care
  • Oil and Gas Production
  • Logistics
  • District heating production and distribution
  • Electricity distribution
  • Public Sector

2 The Method Framework Used

All method components are explained with respect to the core quality objects of the solution, i.e., each component has specific requirements concerning the following:

  • The participating organization, e.g., program management, targeted users, sponsors, ITIL components, COBIT elements
  • The processes used, e.g., participant selection, solution component design, solution integration, normalization of solution data and processes, COBIT elements
  • Solution requirements, e.g., ITIL, facilities, technology
Figure 1: The Agile Strategy Management Method Framework
Figure 1: The Agile Strategy Management Method Framework

The Core Work processes of Implementation, Development, and Quality Management are all established in support of agile behavior, where the concurrent involvement of competent resources ensures fast adaptation to unexpected and risk-managed situations and events. The standard processes and documentation used in the core processes contribute to efficient progress tracking and quality management from the start of a strategic initiative to the delivery of the expected result.

The concrete Techniques and Tools ensure full traceability of all results from idea to solutions in operation. Traceability is especially important while working agile, where results are adapted ongoing to changes in stakeholder demand. The traceability furthermore facilitates the governance of the implemented solution components in the light of changes to their environment and conditions, e.g., ongoing quality improvement.

2.1 Agile Strategy Quality Management

The Agile Quality Management standards used for strategic initiatives comprise:

  • Identification and activation of stakeholders to be involved
  • Communication
  • Team-building
  • Decision-making
  • Management responsibility
  • Documentation

The Quality Assurance and the Quality Control methods of Agile Strategy Quality Management ensure that the key stakeholders are satisfied with the deliverables. The standards are established to be complementary to and sometimes replace components in industry-specific or national method standards for delivery of solutions with this quite ambitious objective: The standards can be understood concurrently by the most hardcore technicians, by the top-level visionary leaders, and by all other strategic initiative stakeholders.

Each strategic initiative stakeholder expects different types of benefits from the initiative, and each one reviews and tests the solution to be delivered for their own reasons, i.e., their proper WHY you need to understand.

The agile ongoing quality assurance of the solution, the organization, and the processes of several strategic initiatives has contributed to the success of the methods.

An important capability of the methods is that they allow for rapid solution development in order to be able to capture the solution benefits while they are relevant. This capability is ensured by early visualization of the complete solution structure and by ensuring that solution elements can be delivered and made productive early during the strategic initiative.

In the context of methodology, no method is perfect and a great number of different industry-, enterprise-, or national-specific standards exist. They are all based on fully valid intentions, but for cultural reasons they respond to their challenge in very different ways. Some methods are prone to flexibility and openness demanding ongoing review and acceptance, while others have extremely rigid structures and rules allowing for continued strict control. ISO standards belong to the flexible type, while DOD standards belong to the more rigid type.

While establishing our specific methods we have tried to provide the following advantages compared with such other methods and standards:

  • People and communication come before processes, and processes come before documentation standards for the very simple reason that no process can run without resources, and even well-chosen people cannot perform well without good processes to govern their work.
  • Documentation standards are simple and cover only the necessary elements. The documentation standards can be seen as a content suggestion or as checklists. Other methods that promote documentation standards differentiated between complex and simple projects are doomed to fail because they never fit all anyway.
  • By providing only basic standards and norms, you give the teams and the competent people the ability to expand to standards of their own that are required for the production of best quality or at least feasible results on their specific tasks. Again people and teams’ freedom to act is in focus.
  • The methods have one basic requirement to all standard documents, which is that they must answer all WHY questions when used, such as these:
    • Why has the team been established the way it is?
    • Why is this objective important for the enterprise?
    • Why is this activity conducted the way it is?
    • Why does this solution component function the way it does?
    • Why is this test done?
    • Why is this suggested improvement an improvement?
      The idea behind this document requirement is that “only if you know and understand the why behind a solution requirement can you give pertinent critique and improve the solution.”

2.2 Quality Management Objects

Quality Management comprises three process management classes with explicitly defined organization requirements, procedures, and result standards:

  • Quality Assurance ensures that a solution will satisfy the stakeholder needs and requirements. This is handled by establishing agreed standards for all resources, procedures, and solution elements to be involved and/or delivered.
  • Quality Control is the ongoing effort to maintain the integrity of a method to be able to achieve the required solution quality. You use communication, interview, and review techniques combined with advanced testing and verification procedures supported by standard Quality Management Information Systems to perform and document quality control.
  • Quality Improvement is the purposeful change of a method to improve the reliability of achieving a required solution. You improve your standards and techniques periodically based on Lessons Learned.

For each quality management process class, you use the three core quality objects as a foundation for evaluation of the performance of this process class:

  • The Solution object defines the properties that are required from the solution to be delivered.
  • The Process object defines the properties that are required for high-performance delivery of the required solution.
  • The Organization object defines the properties that are required for efficient communication, competence establishment, and decision-making.

3 Strategy and Strategic Initiatives

3.1 The Strategy

Corporate leadership establishes the strategy of a corporation. The strategy tells you why the organization has been established the way it is:

  • Organization structure and geographical locations
  • Products
  • Business operations

The strategy comprises these elements:

  • The corporate vision statement that “paints” a picture of how the corporation would like to be observed and how it observes itself in the future
  • The corporate mission that tells a story about how the corporation intends to contribute to the happiness of its stakeholders. This is the strategy quality objective.
  • The confidential corporate objectives known by and sometimes contractually committed to by management tells you the direction followed by the corporation, e.g., these:
    • Internationalization
    • Growth by acquisition
    • Profitability (Return on Investment, Return on Equity)
    • Sustainability
    • Technological superiority

All organizations whether public or private have a strategy and perform business activity governed by this strategy more or less successfully. Corporate management translates the strategy into detailed organizational constructions, business procedures, and strategic initiatives that can ensure and improve the strategy quality.

3.2 The Strategic Initiative

The Strategic Initiatives establish the WHY, the WHAT, the WHEN, the HOW, and the WHO concerned with sustaining, changing, and improving business procedures and infrastructure in support of the corporate strategy.

Strategic Initiatives comprise usually Information System establishment or improvement in support of business operations. Strategic Initiatives are performed as programs and/or projects.

4 Agile Principles

The core agility principle is this: Each process from the definition of the initial need for change to the final delivery of the agreed solution contributes to stakeholder trust, mutual respect, motivation, and willingness to take ownership of the solution components delivered.

5 Strategic Initiative Stakeholder and Scope Establishment

The initial set of objectives provided by corporate leaders are an indication of what kind of business and stakeholders that must be involved in the establishment of the strategic initiative. In most cases these objectives are not precisely defined to establish the full scope of the strategic initiative on their own.

Therefore, the first action in the establishment of a strategic initiative scope is to identify and to have open dialogues with potential key stakeholders to be involved with the initiative, while you respect that you do not know what the real scope is—yet.

In order to identify all stakeholders to get involved or to be communicated with, you get inspiration from analyzing the complete value chain with its areas of operation and organizational responsibility, as illustrated here:

Figure 2 Value Chain Example (http://bettyfeng.us)
Figure 2 Value Chain Example (http://bettyfeng.us)

In several cases, leaving out potential key stakeholders has led to the complete failure of the strategic initiative. Some real and recent examples of less efficient stakeholder management are addressed in 5.1 and 5.2.

A complete quality-assured scope and stakeholder definition follows later through a standardized brainstorm-based process such as Process Quality Assurance (PQA).

5.1 The Private Bank Case

A major private bank established a complex program to automate the private bank, giving all clients access to full web banking. Focus was on technology and functionality, and all of this was successfully implemented and even Accept-Tested and approved before the disaster was discovered:

The bank clients only got involved to enter transactions after the fully integrated solution was technically functional and had been approved from “Friends and Family Testing.” System usage was expected to reach 3000 transactions per day 3 months after the release date. The solution never had more than 300 transactions performed by the users in one day, and in 90% of the cases, these transactions were performed by known Friends and Family testers. Millions of dollars were wasted to such an extent that the stock price fell considerably.

The future users were recognized as stakeholders, but an appropriate dialogue was not established with these stakeholders before it was too late.

5.2 The DANCOIN Cash Card Case

The DANCOIN program was the development and implementation of a cash card in Denmark. Several worldwide-recognized patents came out of this exciting program:

The technical development was a great success. Partners such as banks, credit card facilities, and local transportation were directly involved with finance, development, and implementation. A whole city was set up for Accept-Testing end to end of the integrated solution with service providers and central bank cash and transaction cost clearing. This acceptance test was a great success also seen from a publication and advertising point of view with press and television coverage.

So why did the Danish cash card not have success contrary to basically the same card implemented in, for example, Rotterdam, Holland?

The failure to succeed occurred because of lag of communication with the corporate management people from the core stakeholder, the local transportation organization, HT: In parallel with the DANCOIN development, HT developed their proper card and card reader device for their buses and train stations without coordinating this effort with the DANCOIN project. On the eve of going live, HT refused to implement a DANCOIN reader. Only inferior usage such as a few parking terminals, a few laundries, and some unmanned newspaper kiosks went into production.

This was not enough to pay off the DANCOIN investment, and HT had enough resources to write off their part of the investment.

6 PQA Agile Team-Building

The method to get the teams built and to establish agreement about what the solution will be is the PQA process. PQA is Risk Management-based with focus on Opportunity rather than on Threat. Threat is only treated once that sufficient opportunities (success factors) have been defined.

PQA does not only document what the scope is, but it also documents why the scope is defined the way it is. This ensures the agility of the PQA-defined scope because if any WHY-case changes, then the scope must change. The organization to establish and change the scope is explicitly defined in the PQA result.

6.1 “No Excuse for Failure” Principle

Much too often we have seen projects and major programs moving along with weakly-defined organization of responsibility and activity defined on a level where management is impossible.

Such situations lead to crucial lack of commitment from all involved stakeholders because of these reasons:

  • Results don’t show up.
  • Results show up too late to be useful.
  • Results show up without the quality that was never agreed on or documented.

The “no excuse for failure” principle implies these things:

  • Involved human and technological resources are fully qualified to deliver the required and documented solution.
  • The involved resources are allocated and committed in such a way that their work is done and that the results are delivered without costly interruption, delay, and cost overrun.

The “no excuse for failure” principle ensures that all involved stakeholders are visibly committed and motivated from start to close out of the strategic initiative.

6.2 Simulated Accept-Testing

Communication of real measurable results is performed on a regular basis during Simulated Accept-Testing (SAT) that allows the not-directly-involved business and development stakeholders to evaluate intermediate results. SAT performance allows timely and pertinent decisions about required changes to take place without disturbing the progress of complete solution delivery. The SAT communication ensures that final Accept-Testing becomes a mere formality because all involved stakeholders already know exactly what they can expect from the delivered solution components during final Accept-Testing.

7 Recovery of Projects in Trouble CASE

Much too often professional coaching and facilitation of major strategic initiatives are only called upon when the initiatives get into serious trouble. Most of the time, the stakeholders have tried to implement a solution for months just to discover that no progress (except for spending time and money) has been achieved.

7.1 Medical Factory Implementation Success

A major European pharmaceutical enterprise wanted to implement a big factory to produce medical equipment using cheap raw material to deliver an end product of high quality to be used worldwide at a price to be acceptable even to poor people. The Program was run like a project with one project manager facing several internal key stakeholders with considerable internal power and many external stakeholders with legal and political power. The external stakeholders were delivering these:

  • Buildings
  • Production Machinery
  • QA Equipment
  • Logistics Equipment
  • Internal Machine Control Information Systems
  • Administrative SAP based Information Systems

The internal key-stakeholders were:

  • The future factory manager
  • The CEO

The work to be done was defined at a very low level (work packages by contractor), and a lot of work overlapped between contractors. Arbitration between contractors and the project manager was handled at weekly project meetings. More and more conflicts between all parties surfaced very early. An important reason was that more than one contractor made key decisions, and these decisions were contradictory or at best not visibly aligned with the overall project objectives. This again was caused by the overall objectives being very weakly defined.

The project was finally declared in trouble because major deliveries were slipping without clear responsibility for the delay. It was obvious that a Program organization was needed to govern all stakeholders. Furthermore, a clearly-defined unambiguous requirements specification for each contractor was needed and had to be agreed to by all parties.

The coaching and facilitation services to establish the project as a program that has since delivered one of the most successful solutions in the history of the pharmaceutical industry were these:

  • Establishment of a Program organization based on visible high-level objectives (Critical Success Factors) and clearly-defined high-level activities such that each one was a major project on its own
  • The organization, the objectives, and the activities were approved by top corporate management that became visibly involved in the Program management.
  • Coaching and facilitation of the contractor responsible for delivery of the complete factory control system (a network of control computers connected to the numerical control on all production and Quality Control equipment). This consisted of the establishment of the detailed project plan and the delivery of the method to develop the normalized data structure and content, and the normalized process structure common to all control computers.
  • The normalized data and process structure allowed fast corrections of failures and resolution of problems and ensured an efficient interface to the SAP-based order and production planning and control environment.
  • The normalized data and process structure was used and verified early in Simulated Accept-Testing to prove the efficiency of the solution to be developed and delivered.
  • Facilitation and coaching furthermore involved the the setup and execution of Simulated Accept-Testing supervised by the future corporate management (the Program Management Team) that signed the solution development and implementation off.

The future project manager of the building implementation said: “This process should have been used from the beginning to avoid the troubles that started more than a year ago …”

The methods used were these:

  • Process Quality Assurance to establish the objectives and a complete project plan that allowed reliable estimation, forecasting, and tracking
  • The Information Requirements Study (Object-Oriented Business Analysis) to identify all core objects with their purpose and usage and to ensure that they were complete with respect to the overall success factors for the Program and the detailed success factors for the control system production and implementation
  • The Object Lifecycle Analysis to define and normalize all data and process objects in such a way that all control systems could be developed and implemented where needed, ensuring full integration among equipment, control computers, and with external systems (numerical control and SAP)
  • Simulated Accept-Testing to prove the feasibility of the data and process structure

Both the pharmaceutical enterprise and the control system contractor implemented major method and organization improvements in order to benefit from the methods used also in the future.

8 Conclusion

Qualified and competent people selected to deliver a pertinent solution based on common goals need and deserve the best possible framework of tools and techniques for communication in order to establish a “no excuse for failure” situation without conflicts. The “no excuse for failure” situation allows the involved teams and people to establish complete and pertinent objectives that can be understood and agreed to by all stakeholders. The involved stakeholders want to take ownership of their part of delivered results.

Successful delivery of solutions to complex needs and requirements of strategic initiatives depend on these factors:

  • Your knowledge about all pertinent stakeholders
  • Your ability to get the stakeholders involved with solution delivery from initiation to close out
  • Your capability to keep the stakeholders motivated and as happy as possible throughout the strategic initiative

Agile adaptation to changed conditions is ensured by tracking delivered results early by all involved parties that together possess the competences to do these things:

  • Evaluate results.
  • Make decisions.
  • Initiate work.
  • Perform work.

9 Literature

Soren Lyngso: “Agile Strategy Management, Techniques for Continuous Alignment and Improvement (ISBN-10: 1466596074, ISBN-13: 978-1466596078), 2014

Shaku Atre: “Data base: Structured techniques for design, performance, and management with case studies” (John Wiley & Sons Incorporated, 1988)

E.F. Codd: The Relational Model for Database Management

Chris Date: Database in Depth: Relational Theory for Practitioners (ISBN 0-596-10012-4)

James Martin: Information Engineering, Savant Institute, Carnforth, U.K., 1987

Strategic Information Planning Methodologies, Prentice-Hall, Inc., Englewood Cliffs, New Jersey, 1989

 

Soren Lyngso will be presenting a free webinar with ITMPI on July 5! Sign up here: Strategy Management from Implementation to Governance with People Focus

About Soren Lyngso

Soren Lyngso, MA (Econ) from Copenhagen University, PMP, General Manager, Author, Facilitator, and Coach has more than 30 years of experience from general, project, and program management and from implementation of complex business and IT solutions in different industries and countries. Experience has been gathered from Danish and international projects spanning maintenance of oil production platforms, factory implementation in the pharmaceutical industry, container line system implementation, distribution of toys, cash card system implementation, defense facility management, and in private banking and asset management solution implementation. Currently his main occupation is teaching and coaching project and program managers on all levels in Europe and the Middle East – the favorite subject being “Rapid Assessment and Recovery of Projects in Trouble”. He has published his quality model for strategically aligned solution implementation on his website, www.lyngso.lu.

Check Also

Agile at Scale Enables Your Grilled Cheese Sandwich

I had sharp cheddar cheese and butter in the fridge, but no bread. So, I …

Leave a Reply

Your email address will not be published. Required fields are marked *