Director at Large, Project Management Institute, Southern Italy Chapter, Naples, Italy ... Although the Office of Government Commerce's Managing Successful.
AGILE PROJECTS AS MICRO-PROGRAMS: A UNIFYING APPROACH Pietro Casanova, PMP® Independent Sr. ICT & PM Consultant, Director at Large, Project Management Institute, Southern Italy Chapter, Naples, Italy ABSTRACT Projects and Programs are initiatives aimed to producing change. However, so far traditional projects have been conducted as tactical initiatives whose main objective has been the optimal release of planned results, without any consideration on whether such results would eventually deliver real value for the sponsoring organization. In the IT field, agile project management is successfully adopting a new value-oriented approach to deliver on time and on budget. Current research has shown how the Agile Project Management philosophy is in line with the Program Management one, even as far as strategy alignment and value realization is concerned. This paper analyses fractal self-similarities in the management of both agile projects and programs, which, beside a unifying model for both Program and Agile project methods, offers the opportunity to naturally support the organization of a holonic collaborative information ecosystem.
1
INTRODUCTION
For a long time, the traditional project management approach has been questioned due to the large number of failing projects. As Michel Thiry reports [15, p. 13], “well published large scale studies (Standish Group 1996; KPMG, 1997) ….exposed the failure of traditional project management methods to respond to emergent situations and to ambiguity, as well as the lack of integration between strategic intent and the result of the maturing of the project management discipline at about the same time these studies were published”. At least in the case of IT projects, market globalization and related growing organizational and productive complexity are pushing for more flexible and participatory management approaches [2] which could ensure reliable business value realization by means of both adaptive continual change and team empowerment strategies. Some projects, such as accounting systems ones, are fairly simple to implement, because of very static requirements and available knowledge. Such projects can be handled well by means of traditional project management methods. In many other cases, however, due to lack of knowledge, fast moving scenarios, short time frames, complexity and many other reasons, traditional project management is not able to properly take care of the project’s inherent ambiguity, that is the number of non-clear paths relating to both different possible decisions and different stakeholder’s perception of value, which have an important influence on objectives change over time. Some researchers state that the traditional hierarchical command-and-control chain does not work well in this case [6]. First because it slows down decisions, even when they are technical ones. Then, upfront plans are hard to keep updated and dispatching tasks assumes that operating conditions at the dispatching time are the same as at planning time. For complex, demanding projects continuous and prompt scope changes throughout their life cycles must both be expected and properly coped with. For them, decisions need to be taken horizontally, thus allowing more decisional power to the project team. Team empowerment is not only a need of fast decision making. It is regarded as providing a solution to the age-old problem of Taylorized and bureaucratic workplaces where creativity is stifled and workers become alienated, showing discontent through individual or collective means. Some see this management shift “as revolutionary as the assembly line” [5] However, traditional project management methods are not the only cause of such project failures. Particularly in the IT field, a major problem derives from important misalignments between strategic intent and project results. This has been a consequence of the old perception of IT departments as an outsourced workhorse with little contribution to business. Even in the case of proper project charters and business case inputs, so far IT projects have been conducted mainly as tactical initiatives whose main objective has been the optimal release of planned capabilities, without any consideration on whether such results would eventually deliver real value for the
-1–
sponsoring organization. Both strategic managers and project managers have traditionally tried to keep change to a minimum because it affects their plans. In traditional project management respecting the initial up-front project scope definition and detailed plans is mandatory, even when new situations and better scope understanding arises during the project lifetime. This won't work anymore! Complex situations, where multiple stakeholders compete with each other and try to influence the outcome on a continual basis, create ongoing change, requiring constant adjustment of the plan through a series of integrated, mutually reinforcing decisions that form a coherent whole. In order to cope with such complex situations and turbulent environments during project execution, first Program Management and then Agile Project Management were introduced. Programs have evolved from being large projects made of subprojects to “a group of related projects, subprograms and program activities that are managed in a coordinated way to obtain benefits not available from managing them individually” [12]. Although the Office of Government Commerce’s Managing Successful Programs definition is slightly different: “a temporary flexible organization created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to organization’s strategic objectives” [10], both definitions underline the same final goal of managing related projects and activities in order to realize the benefits needed to produce some specific planned business value in alignment with the relevant strategic objectives. Both projects and programs are temporary organizations, that is organizations set-up and operating just for the project or program time-frame. Such temporary organizations are aimed to producing change. Programs are generally complex and business focused in order to produce business benefits through multiple deliverables with frequent realignments to the business strategy. As such a program can be seen as a “Complex Adaptive Model of Organization Change”[11], since it emphasizes the need to adapt to “unknowable, unpredictable and uncontrollable” behaviors, to accept the fact that cause and effect are not necessarily related in a linear way and that people need to be empowered and organizations responsive. Therefore, a program “becomes the transition stage towards a transformation state that is yet to be detailed. These are cases where the program is used as a vehicle for social interaction between stakeholders to generate new patterns of behavior, creative ideas and innovative products that increase the organization’s competiveness” [15, p. 34]. This approach requires strong collaboration and a knowledge-sharing culture where multiple stakeholders will work together to define the blueprint of the future business and be ready to commit to a vision that may not yet be fully formed. Agile project management is emerging as a very pragmatic approach mostly for small/medium IT project implementations with high decisional ambiguity. In addition to team empowerment, agile methods promote, amongst other things, business value realization by means of both an active customer representative integration within the project team and continuous incremental delivery. Agile principles emphasize building working products that people can get hands on quickly, versus spending a lot of time writing specifications up front. In addition to rapid iteration, with continuous customer input along the way, Agile development projects focus on cross-functional teams empowered to make decisions, versus big hierarchies and heavy functional organizations. In agile projects, stakeholder communication is based on information radiators, that is large visual synthetic representations of all relevant project information and its progress towards the deliverable; rather than large upfront documents and status reports as found in traditional project management. Burn-down or Burn-up charts as well as Task or Kanban Boards are some examples of such visual representations. The goal of the information radiators is to make it clear to everyone and anyone who is interested, exactly what is happening with the project. When ambiguity is relevant in a project, fixing its scope upfront and demanding to keep it fixed, as is the case for traditional project management, is a serious cause of failure, giving rise to substantial schedule and cost expansion. In this case it is much more effective fixing the duration and cost of the project and controlling its scope as it evolves to produce the required business value for which the project has been started. Therefore a shift is needed from a requirements-based approach to a time-based one. As shown in the following figure, in agile projects, the so-called iron triangle is reversed upside-down, with time, cost and quality that should never be changed, even at the expense of scope. Moreover, the monitoring and control model, which, in the case of traditional project management derives from the continuous system control theory and is similar to the one used for controlling, e.g., thermostats, for complex projects is not at all sufficient, since it lacks learning and improvement during project execution. Lessons learned are postponed to future projects, thus not allowing to -2–
find reasons for deviations, and eliminating those root causes during project execution. This implies that the Plan-Do-Check-Act (PDCA) quality cycle used for traditional project management be enhanced to Plan-DoCheck-Learn-Act (PDCLA), as pointed out in [4]. Agile project management takes care of this aspect by means of retrospective activities which are performed at each iteration and condition the way following iterations will be implemented.
Fig. 1. The Iron Triangle for Traditional and Agile Project Management
There are very strong similarities between Agile projects and Programs. Michel Thiry has discussed such analogies in various articles [16], [17], [18]. Starting from a previous work [4], below we are going to discuss in detail such similarities and will analyze how a unifying pattern is possible that scales agile development projects to programs. This could be very important in order to achieve a unique way to handle both cases and offers the opportunity to naturally support a holonic information ecosystem [21].
2
THE ANALOGY BETWEEN AGILE PROJECTS AND PROGRAMS
In the case of Agile project management “the backlog is sometimes referred to as a portfolio of options that the business can invest in“ [7, p. 71]. It is soon clear that the approach of selecting investment items, prioritizing and keeping them aligned to strategic requirements is a common characteristic that links portfolios, programs and agile projects. This might induce to the conclusion that these three management approaches are very similar. Portfolio management, however, is an on-going decisional activity that is repeated indefinitely in the life of an organization, whilst both Program and Agile Project Management are constrained in time and need to cope with relevant uncertainty. In addition to a need to realize strategic business value, the evolution of programs to the current conceptualisation derives from the complexity created by interrelated projects and multiple stakeholder and the ambiguity involved in constantly emergent decision making. These are basically the same reasons that led to the introduction of Agile methods in order to overcome the evident inadequacy of traditional approaches for software projects, which are mostly complex, fast moving and often innovative. Therefore both programs and Agile projects are change actions whose objective is value realization. In addition to a high level of uncertainty, they are characterized by a high level of ambiguity, requiring a more both flexible and rapid decision-making approach, as shown in the following figure (see [14], p. 115).
Fig. 2. Ambiguity and Uncertainty in Programs and Agile Projects
-3–
On the contrary, execution actions, such as operations management and traditional project management, are characterized by low ambiguity and differ by the level of uncertainty, which is high for traditional project management. As for Programs, Agile projects are aware of the initial uncertainty about both direction and outcomes; and they are carried-out in a way that decisions can be taken at their best, given all ambiguity factors. Agile projects, as programs do, do not commit to a very precise schedule at inception, but do elaborate, clarify and adjust scope and directions continuously. Michel Thiry states that the Agile Software Development principles “could very well apply to program management” [16]. In the same article he lists a number of common concepts relating to program management and agile management, as follows: Responsiveness as a measure of value (change as opportunity, rather than threats); in contrast with the case of traditional management, where efficiency and reliability is pursued; Evolutionary and adaptive development, which translates into gradual and measured release of benefits; Team as integrated evolving system where all key stakeholder are actively involved; Approach based on simplicity to improve response to changing demands and turbulent environments. We can add that both Agile projects and Programs are conducted to produce outcomes, rather than just outputs as in the case of traditional projects. There is difference between outputs and outcomes. According to the Concise Oxford Dictionary, output is the “product of a process”, whilst outcome is defined as a “result” or a “visible effect”. A benefit is “the measurable improvement resulting from an outcome which is perceived as an advantage by one or more stakeholders” [10]. Hence, for both Programs and Agile projects, the final mission is to deliver outcomes, supplying capabilities and benefits to the organization in order to realize its mission and vision through their organizational strategy. For such a reason this approach is sometimes classified as Outcome Management, in contrast to the traditional Output Management philosophy. The table below, adapted from [3], shows the main differences between traditional project management and outcome management. Table 1. Traditional Project Management vs. Outcome Management
One consequence of such common Outcome Management approach is that Agile Project Management needs to deal with the same process domains as the ones stated in PMI’s Standard for Program Management. [12]
Strategy Alignment; Benefits Management; Stakeholder Engagement; Governance; Life Cycle Management
-4–
Agile Project Management methods mostly do not explicitly refer to strategic plans and strategy alignment and most agile teams are concerned with three levels of planning only: day, iteration and release. However, Agile Projects are conducted in a way to produce the maximum business value at the minimum cost and time. As Mike Cohn points out “outside the concern of most individual agile teams…are products, portfolio and strategic planning”. [19, p. 28] As for programs, agile projects are carried-out using an ongoing, dynamic oversight approach to realize the requested benefits as the initiative unfolds. PMI Program Management Standard [12, p.34] states that Benefit Management is made of the following processes, applied iteratively: Benefit identification; Benefit Analysis and Planning; Benefits Delivery; Benefit Transition; Benefits Sustainment. Analogous processes are applied iteratively in Agile projects under responsibility of the Product Owner or whoever is responsible for the business in the team. In the case of programs, initial benefits identification is made during the initial Program Formulation Phase with the contribution of the program manager selected by the program sponsor as the only person belonging to the program team allocated to the program in this phase. Program justification, vision, strategic fit and boundaries, benefit strategy, risks, timeline, resources requirement, stakeholder considerations, assumption and constraints are defined. Key benefits are identified as outcomes. All this information is documented in the Program Charter and a Program Roadmap is prepared. Although Agile methods mostly do not explicitly address this initiation phase, Agile projects are initiated in a similar way, and their charter states expected benefits and outcomes, as for programs. The way the project benefits are analyzed and planned is conceptually equivalent to what happens for programs, though less bureaucratic. Benefit realization is difficult to measure and in many cases it cannot be measured and controlled without real application of the outcomes produced by the project/program. In the case of Agile projects, the continuous support of a customer/user representative, the iterative development approach and the continuous deployment strategy, is a very effective way to measure and control incremental benefit realization by means of timely feedbacks by all relevant stakeholders. Stakeholder engagement is fundamental in producing the outcomes that are needed. This is true not only for Agile Projects but also for Program Management and even for Traditional Program Management as explicitly recognised by PMI in their latest version of the PMBOK Guide [13], where a new Knowledge Area that copes with Stakeholder Management has been explicitly introduced. Such management activities are performed in a similar fashion in al three contexts. Managing stakeholder is not always possible, of course, and it is not the purpose of this management activity. Therefore here, more properly, we talk of Stakeholder Engagement to actually mean the management of Stakeholder Engagement and the engagement activities too. In addition to the correct communication with all key stakeholders, so that they can be continuously informed about the progress of the initiative and kept aligned, Stakeholder Engagement relies on relational aspects and negotiation. It starts identifying both the program stakeholders and how the program will affect them (e.g., the organization’s culture, current major issues, resistance or barriers to change, etc.). Then a communication strategy to engage the affected stakeholders is developed, their expectations is managed, and their final acceptance of the delivered outcomes is improved. As usual, in the case of Agile projects, the Stakeholder Engagement plan is a straightforward table pinned on a Kanban or equivalent board. Governance is “the process of defining and maintaining direction, putting in place the structures necessary to ensure success and making sure the stated objectives and benefits are achieved. Harmonization is necessary to create synergy between different interrelated actions and their outputs to deliver an integrated outcome” [15, p.16]. In business, often governance is associated with disaster prevention and risk mitigation, thus implying tighter controls. However, as for the case of both Programs and Agile projects, governance should be devoted to the sustainment of a value creation perspective, that is maximizing opportunities rather than reducing threats. A vision and relevant objectives should set the direction needed in order to achieve strategic goals and stakeholder needs. Both Agile project and program governance result in a framework for efficient and effective decisionmaking and delivery management focused on achieving project/program vision and goals in a consistent manner, addressing appropriate risks and stakeholder requirements and realigning the scope as needed. This requires team empowerment in order to avoid bureaucratic impediments. For both Agile projects and complex, fast moving programs, traditional decision making approaches are too slow and are not adequate. In these cases stakeholder requirements and expectations require a learning cycle based on sense-making, ideation and elaboration. Decisions are taken jointly based on such elaborated situations. Sense-making is “an emergent -5–
activity – a capacity to move between heuristics and algorithm, intuition and logic, inductive and deductive reasoning, continuously looking for and providing evidence and generating and testing hypotheses, all while ‘playing the game’ “ [1]. In a simplified way, sense-making can be seen as the ability to discover and comprehend actual situations while they develop, that is, give meaning to experience. It assumes and recognizes that human beings play a significant role in adapting and responding to unexpected and unknown situations, as well as expected ones. Both Programs and Agile Projects proceed through similar life-cycle phases, as shown in the following figure. For Agile Projects, the Initiation and Planning phase is very light since details are to be avoided at this stage and will be developed as the project advances. Both the Agile Project Starting phase, also called iteration -1, and the Program Formulation one are ultimately meant to secure financing and produce a Charter and Roadmap. Program and Project Charters are conceptually very similar, expressing, among the other things, initiative justifications, vision, outcomes, initial risks and issues, timeline, resource needed and success criteria. It is important that in the case of Agile Projects, such Charter be very synthetic, fitting in no more than one A4 sheet. Its main purpose is to provide a clear and concise success definition for the initiative and making such information easily available to all relevant stakeholder. Therefore, it is essential that all influential stakeholder participate in its creation. Tabel 2. Program vs Agile Project Life-Cycle Phases PROGRAM LIFE-CYCLE Program Definition Program Formulation Program Preparation
Program Benefits Delivery Program Closure
AGILE PROJECT LIFE_CYCLE Program Initiation and Planning Project Starting Project Organizing and Preparing
Carrying out the work (Project Benefits Delivery)
Project Closing
Both Program Preparation and Agile Project Organizing and Preparing, also called Warm-up or Iteration 0, aim to establish the conditions for governance and organization of the initiative. Agile processes are much lighter than the corresponding Program ones with as little documentation as possible.
3
MANAGING AN AGILE PROJECT AS A MICRO-PROGRAM
Programs, as they are defined nowadays, are an evolution of large project initiatives from output management to outcomes management, and are a means to produce planned benefits, strategic alignment and stakeholder satisfaction. On the other hand, Agile projects, represent a similar evolution for small IT software development initiatives. Their analogies, as discussed in the previous section, are such that we might think of Agile projects as small programs, where a backlog is a sort of small inventory of work defined in order to deliver final benefits, as required by its vision, strategic objectives and stakeholder changing requirements. As we have seen, even Program’s and Agile project’s delivery lifecycles are analogous.
Fig. 3. Structural Self-similarity in Agile Projects, Programs and Portfolios
-6–
From a structural point of view, portfolios, programs and agile projects could be considered sort of “fractal patterns”, that is patterns that repeat themselves at different scales by means of “self-similarity” (see “fractal” on wikipedia). Fig. 3 shows how, from a structural point of view, agile projects scale up to programs and programs to portfolios. Notice that self-similarity as shown in exhibit 3 includes multi-team agile projects. In the real world this is becoming an important extension to the basic agile development projects which assume a single team of around 10 people maximum.
Fig. 4. Agile Projects – not just Agile Software Development
Naturally this implies a more appropriate level of management with respect to the self-organizing team of the basic agile development project and is a necessary condition to promote the adoption of agile management with bigger initiatives, even with mixed management approaches, as shown in the figure above. Table 3. Comparative Overview of Agile Project, Program and Portfolio Management Agile Projects
Scope
Project Vision and objectives drive the attainment of desired business value by means of specific related component work backlogs. May not have the entire scope determined upon initiation. During its lifecycle, Scope is continously elaborated, clarified and adjusted to ensure alignement of outcomes with intended benefits.
Change
Change is expected from inside and outside the project and is managed as needed to ensure alignement of outcomes with intended benefits.
Planning
Overall Project Plans are developed proceeding through a Business Case , a Project Charter , a Project/Product Plan (containing: Product Vision ; Product Goals and Objectives ; Success Criteria ), an overarching Product Roadmap and a Release Plan .
Management
Success
Monitoring
Provide Vision and Overall Leadership over the whole project team or, in case of multi-team projects, the Team Leaders. In simple situations a proprer Project Management Plan is not needed, though multi-team and mixed project approaches might require some simple management plan statement. Success is measured by the degree of required benefits realization and stakeholder satisfaction in the respect of planned duration, cost and quality. Information radiators allow stakaholders to continously monitor the progress of the project. Colocation, Daily Team Meetings and Timebox Review Meetings insure adequate straightforward monitoring and control.
Programs Program Vision and objectives drive the attainment of desired business value by means of specific related larger component work backlogs. May not have the entire scope determined upon initiation. During its lifecycle, Scope is continously elaborated, clarified and adjusted to ensure alignement of outcomes with intended benefits. Change is expected from inside and outside the program and is managed as needed to ensure alignement of outcomes with intended benefits. Overall Program Plans are developed and high-level component plans are created to guide detailed planning. Overall planning proceeds through a Business Case ,a Program Charter , a Program Plan (containing: Program Vision ; Program Goals and Objectives ; Success Criteria ) and an overarching Product Roadmap . Provide Vision and Overall Leadership over the program staff and the Project Managers. A Program Management Plan which guides the Program management activities is developed iteratively and updated as needed. Success is measured by the degree of required benefits realization and stakeholder satisfaction in the respect of planned duration, cost and quality. The progress of the Program's components is regularly monitored and controlled to ensure maximum possible benefits realization and stakeholder satisfaction in the respect of planned duration, cost and quality.
Portfolios Strategic Vision and Strategic Objectives drive the attainment of desired business value by means of specific unrelated strategic investment initiatives. Scope is continously monitored and adapted to both changing strategic requirements and investment capacity.
Change is continously monitored internally and externally to ensure alignement with both Strategic Vision and Strategic Objectives.
Overall Portfolio Plans are developed proceeding from the Organizational Strategic Plan and Objectives , through a Portfolio Charter , a Portfolio Strategic Plan, and an overarching Portfolio Roadmap
Manage or coordinate Portfolio Management Staff other than the Program Managers and Project Managers with reporting responsability into the aggregate portfolio. A Portfolio Management Plan which guides the Portfolio management activities is developed iteratively and updated as needed. Success is measured as the aggregate investment performance for the level of required strategic objectives realized. Strategic Changes, Aggregate Resource Allocation and Portfolio Risks are continously monitored and controlled to deliver the required performance results.
-7–
Whilst structural self-similarity between Agile projects, Programs and Portfolio is quite evident, from a management point of view this does not seem to be as evident. In this case, as shown in table 3, we can imply a high degree of self-similarity between Agile projects and Programs, whilst self-similarity becomes wicker between Programs and Portfolios. One way to improve self-similarity between Agile projects and Programs would be Program time-boxing with a Program cadence being a multiple of the related project cadence, which should be the same for all projects included in the program. Also the Project’s daily review meeting should scale to a weekly or biweekly review meeting among Program staff and Project/Activity Managers. For Programs, team empowerment is quite natural, since each Project/Activity Manager is autonomous in his project delivery activity and overall decisions could be taken jointly by the Program Team, including the overall Product Manager who represents both the Business and the final customers.
4
CONCLUSIONS
Agile methods are having a huge impact on the software industry. Currently, agile Software development projects tend to constrain the initiative to a single team of around 10 people maximum. They assume team selfmanagement and time-boxed continuous delivery of implemented selected components from an inventory of prioritised work, towards the gradual iterative availability of outcomes and capabilities useful to produce specific business value. As such they represent a very simplistic case of real larger multi-team and multi-process project situations.. Scaling development agility to less trivial projects and up to programs does not seem that easy, particularly for the kind of fracture between a self managed environment and a hierarchically managed context, such as the one for traditional projects and programs. Nonetheless, Agile Team Developments contain many important similarities with respect to Programs to such a degree that they might be considered quasi miniature programs. Actually, the same performance domains for management can be found in both Programs and Agile Team Developments. Also, it is more and more accepted that many management practices, such as: visioning and strategic alignment; benefits management; stakeholder engagement; customer integration, should be carried-out in a similar way in both contexts. Naturally in the Agile Team Developments case, performance domains have a different impact on the initiative’s organization structure and governance with respect to the case of Programs, but such similarities give the possibility to evolve agile scalability by “polishing” both Program and Agile Team patterns in order to make them fully self-similar. For example, in the case of Programs, simplifying their organization, introducing time-boxed delivery and weekly review meetings. Some agile scaling methodologies like Scaled Agile Framework have already introduces a few such characteristics [8]. The complexity and rapidity of current global business is such that now business leaders are looking for ways to reap the benefits of agile principles in whole-organization governance and management. Having a unique method for agile project management, that scales up from Team Development to Multi-Team, Multi-Process Projects to Programs, is very important in order to scale the benefits of agile principles to the whole organization and allows to implement a cultural and organizational simplification with high responsiveness. In addition, treating an agile project as a small program allows to set back enough project control in order to overcome the current contractual issues of outsourced projects, without affecting all basic agile principles, such as team empowerment and Just-in-Time scope development. This approach fist naturally in the nested hierarchy of fractal entities named a holarchy [20]. Scaling up further from Agile Programs to Agile Portfolios contains several problems and does not seem to be conceptually possible. Mainly, although a Portfolio can be seen as an inventory of work like programs and agile team developments, it is managed as ongoing work without a specific start and end date. We think that this could be overcome by setting time limitations to Portfolio Management producing alignment with the Strategic Review pace, e.g. yearly or biyearly. However this requires a more precise investigation that should also consider emergent strategy, as opposite to deliberate strategy [9] . This article reports an initial analysis. It shows how multiple granularity manifested through replication into agile project management self-similar fractal structures at multi-resolution levels can naturally support holacratic organizations [20] and their related collaborative information ecosystems [21]. We hope to continue this work in the future in order to propose a straightforward full agile fractal pattern. -8–
REFERENCES 1. 2. 3. 4. 5. 6.
7. 8. 9. 10. 11. 12. 13. 14.
15. 16.
17.
18.
19. 20.
21.
Ancona, D.: Sensemaking: Framing and Acting in the Unknown. In: Scott, S., Nohria, N., Khurana, R. (eds.) The Handbook for Teaching Leadership, pp. 3-19, Sage Publications, London, UK (2011) Bartle, P.: Participatory management. Methods to increase staff input in organizational decision making. (2007). Retrieved from http://cec.vcn.bc.ca/cmp/modules/pm-pm.htm Bhawnani, P.: Outcome Management Vs. Project Management. (2010, April) Retrieved from http://pbhawnani.blogspot.it/2010/04/outcome-management-vs-project.html. Casanova, P.: Agile processes: a unifying approach for the future of projects, PMI EMEA Global Congress 2013, Istanbul, Turkey (2013, April) Fryer, B., Stewart, T. A.: Cisco sees the future: an interview with John Chambers, Harvard Business Review, 86(11), pp. 72-79 (2008). Koskela, L., Howell, G.: The underlying theory of project management is obsolete, Proceedings of PMI Research Conference 2002, Seattle, WA, Newtown Square, PA: Project Management Institute, pp. 293302 (2002, July). International Institute of Business Analysis. (2011, November). The Agile Extension to the BABOK® Guide – Draft for Public Review. Toronto, Ontario, Canada: International Institute of Business Analysis, p. 71 Leffingwell, D.: Scaling Software Agility: Best Practices for Large Enterprises, Addison Wesley Professional (2007) Mintzberg, H.: Patterns in Strategy Formation, Management Science, Vol 24, No 9, 1978, pp 934–948. Office of Government Commerce: Managing Successful Programmes – Third Edition. London, UK: The Stationery Office (2007) Olson, E. & Eoyang, G.: Facilitating Organization Change: Lessons from complexity science. JosseyBass/Pfeiffer, San Francisco (2001). Project Management Institute: The Standard for Program Management - Third Edition. Project Management Institute, Newtown Square, PA (2013). Project Management Institute.: A Guide to the Project Management Body of Knowledge (PMBOK®Guide) Fifth Edition, Project Management Institute, Newtown Square, PA (2013). Thiry, M.: Program Management: A Strategic Decision Management Process: In Morris, P., Pinto, J. K. (eds) The Wiley Guide to Project, Program and Portfolio Management. pp. 113-143 , J. Wiley & Sons, Inc Hoboken, New jersey (2007) Thiry, M.: Program Management. Gower publishing ltd, Farnham, Surrey, UK (2010) Thiry, M.: The synergy between Agile and program management. Project Manager, Education & Opinion (2012, September). Retrieved from http://projectmanager.com.au/education/methodologies/synergy-agileprogram-management/ Thiry, M.: Agile, programs and benefit management. Project Manager, Education & Opinion. (2012, October) Retrieved from http://projectmanager.com.au/post-project/benefits-realisation/agile-programsbenefits-management/ Thiry, M.: Governance for programs and Agile projects. Project Manager, Education & Opinion. (2012, November) Retrieved from http://projectmanager.com.au/education/methodologies/governance-forprograms-and-agile-projects/ Cohn, M.: Agile Estimation and Planning. Prentice Hall – Robert C. Martin series, Upper Saddle River, New Jersey (2005) Robertson, B. J.: Holacracy: A Complete System for Agile Organizational Governance and Steering. Agile Project management, Vol. 7, No. 7, Cutter Consortium. Retrieved from http://library.uniteddiversity.coop/Decision_Making_and_Democracy/Holacracy_-_Robertson.pdf Ilieru, M., Walker S. S. and Brennan R. W.:The Holonic Enterprise as a Collaborative Information Ecosystem, Workshop on “Holons: Autonomous and Cooperative Agents for the Industry”. pp 1-13, retrieved from http://www.google.it/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CEAQFjAA&url=http%3A %2F%2Fwww.researchgate.net%2Fpublication%2F229033865_Holonic_enterprise_as_a_collaborative_in formation_ecosystem%2Ffile%2F9c960520a97e7b8b75.pdf&ei=i8h_Uqs-
-9–
iPXhBMHYgPAO&usg=AFQjCNGwgO_GwE8Bu6AxEDOxKuJ2SU2obA&sig2=Fg5I4525ut6g5E5ImP gSKw&bvm=bv.56146854,d.bGE&cad=rja
- 10 –
