Spa - Systemic Project Alignment


Published on

this presentation describes the idea of organizational support for projects to improve IT projects success rate.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Spa - Systemic Project Alignment

  1. 1. SPA – Systemic Projects Alignment<br />On “soft” Aspects of IT Project Management<br />Daniel Ofek<br />
  2. 2. What?<br />On IT Project distress<br />Human factor in IT projects<br />Effective behavior in projects<br />Systemic thinking in projects context<br />
  3. 3. What is a Project?<br />A project is a one time planned effort, composed of activities performed by professionals in order to reach pre-defined results by using pre-allocated resources<br />Project results is a product or a service<br />Every project has a customer<br />Every project meant to promote a bigger goal of the organization<br />A project is a process of change and learning – by its completion the organizations is different. The people who took part in it are different too<br />
  4. 4. The Challenges<br />July 09<br />
  5. 5. What’s Going-on with IT Projects<br />Large Scale IT Projects<br />Source: Standish Group “Chaos Reports” 2006<br />
  6. 6. Why Projects Fail -Testimonals (1)<br />Project has no published vision<br />Too much focus on technological issues<br />No clear division of responsibility<br />Managing tasks instead of outputs<br />Poor risk management<br />Episodic approach to project<br />Matrix structure increase conflicts, disputes, lack of commitment<br />People don’t believe in: managers, product, plan, each-other<br />Vicious circles drive the projects<br />
  7. 7. Why Projects Fail -Testimonals (2)<br />Many activities are performed with no project framework<br />The project solves the wrong problem (sold by hungry salesperson)<br />The solution is of “soup of the day” type<br />Trying to do the best – instead of the right<br />
  8. 8. Why Projects Fail –Testimonals (3)<br />Bad project management (in-experience, poorly trained, poorly selected….)<br />Plan (and scope) are irrational<br />Wrong WBS and personnel assignment<br />Bad manning – inadequate team members<br />Bad quality product<br />Too many changes, poor productization<br />Wrong mix of technology and interfaces<br />
  9. 9. Why Projects Fail -Testimonals (4)<br />Lack of company commitment<br />Lack of requested knowledgein company and among project members<br />Missing sponsors from company and customer<br />Too complex processes<br />Passive not involved customer<br />Weak agreement between stakeholders regarding the solution<br />
  10. 10. An Industry Leader Definition of the Cause of the Problems<br />Question: Are most project failures caused by technical problems, people problems or business problems?<br />Answer: People problems. Business and technical problems boil down to people problems. People solve problems. People create problems. <br />It&apos;s the extent to which we take responsibility for solving problems that gets them solved. <br />The myth of IT is that it&apos;s about computers and technology. It&apos;s not -- IT is about people. From: Sue Young CEO of ANDA Consulting in Colchester, VT<br />
  11. 11. Project Management Body of Knowledge-PMBOK<br />The five process groups are:<br />Initiating, <br />Planning, <br />Executing, <br />Controlling and Monitoring, and <br />Closing. <br />The nine knowledge areas are:<br />Project Integration Management <br />Project Scope Management <br />Project Time Management <br />Project Cost Management <br />Project Quality Management <br />Project Human Resource Management <br />Project Communications Management <br />Project Risk Management <br />Project Procurement Management <br />
  12. 12. PMBOK - Human Resource Management Chapters<br />Focus on human as resources:<br />9.1 Human Resource Planning<br />• 9.2 Acquire Project Team<br />• 9.3 Develop Project Team<br />• 9.4 Manage Project Team<br />
  13. 13. Background<br />July 09<br />
  14. 14. Project Management Dimensions<br />Organizational<br /><ul><li>Structure
  15. 15. alignment
  16. 16. Teams
  17. 17. Knowledge
  18. 18. Communication</li></ul>Infrastructures<br />
  19. 19. Classifying your Project (what’s missing?)<br />Unique expertise<br />Global Developments<br />technology<br />Quality Standards<br />Determining the<br />Critical<br /> Success Factor<br />Cost objective<br />Multi-disciplinary<br />Timecrucial<br />Human<br />outsourcing<br />complexity<br />Evolution<br />Revolution<br />Company importance<br />Life dependant System <br />Rich feature set<br />Legacy knowledge<br />Available test equipment<br />15<br />Time to Market Goals<br />Risks<br />Multi Project Org .<br />SW intensive<br />Version release policy<br />Infrastructure ReUse<br />Budget <br />In-house knowledge<br />stakeholders<br />Novelty <br />Off-shoring<br />Taken from PM course<br />ETC ….<br />State of the Art <br />HW or SW Project ?<br />
  20. 20. Iceberg model of PM and Problems Solutions<br />Solutions Elements<br />Management Elements<br />Integration, Content<br />Time<br />Cost, Budget, Pro-curement<br />HR Management<br />Formal Comm<br />Risk Management<br />Change Scope<br />Technical Change<br />Increase Budget<br />Reduce Cost<br />Replace People<br />&quot;Investigation Committee”<br />Change Co-efficients<br />Project Products<br />Formal Management Procedures<br />Informal Management <br />Procedures and Relationships<br />Culture<br />Mood<br />Commitment<br />Politics<br />Leadership<br />Informal Comm<br />Cooperation<br />Knowledge&Und-erstanding<br />Systems Thinking<br />Info sharing<br />Align with supra-system<br />Support Leadership<br />HR-Human Relationships<br />
  21. 21. Project Management Theories<br />
  22. 22. The Space of Org Support in Projects<br />Project specific <br />org. parameters<br />Leadership<br />External Comm &<br />PR<br />The more dynamic and less stable is the project environment, the greater need of fostering the organizational aspects<br />Knowledge &<br />understanding<br />Systemic vision<br />Commitment<br />Mood<br />Human relationships<br />Org structure<br />Culture<br />Project<br />Life-cycle<br />Internal comm<br />People Placement<br />& HRM<br />Emergency<br />Implemen-<br />tation<br />Planning<br />Initiation<br />Execute<br />Closure<br />Maint<br />enance<br />
  23. 23. Supporting the Project<br />Management consultant<br />Technical Consultant<br />SPA<br />Org. Consultant<br />
  24. 24. Project Vs. Company<br />Learning most often begins with a small group and only gradually <br />spreads across the organization and then up<br /> Edgar H. Schein 2002<br />
  25. 25. In-Project Behavior – What is it?<br />Every project member performs specific functions within the project<br />The In-Project Behavior (IPB) is the way in which these functions are performed<br />Functions performance is a product of the following dimensions:<br />Behavior - leadership, sharing, trustfulness, biases…<br />Mental conditions – commitment, motivation, mood, pride…<br />Professional infrastructure – specific and background knowledge, experience, competencies …<br />Personality – traits, character …<br />
  26. 26. In-Project Behavior - Principles<br />IPB is derived mainly from 1. personal, 2. project characteristics 3. peers IPB<br />Every project has IPB “State of Aggregation” – the total effectiveness of IPB<br />Improving IPB is a learning process (not just managerial)<br />Teaching IPB is by courses or personal coaching<br />
  27. 27. IPB Improvement<br />IBP improvement is composes of the following items:<br />Defining best IPB for the project (in context of the organization, market, technology)<br />Identifying the gap between actual individual and team IPB and the required effective IIPB<br />Design and implement activities to reduce this gap<br />
  28. 28. Systemic Thinking<br />It is possible to improve IPB by adopting systemic thinking approach throughout project life-cycle<br />Un-solved chronicle problems are largely the result of a systemic failure and not human errors <br />
  29. 29. Systemic Approach to Projects<br />The Project is a system is a system is a system...<br />July 09<br />
  30. 30. Systemic Approach to Projects<br />Every project constitutes an open, dynamic, complex and learning system<br />The systemic approach uses two lenses simultaneously to investigate the situation<br />Concave – enables to see the full picture<br />Convex – enables to get down to details<br />
  31. 31. Customer<br />Company<br />Project’s Ecosystem<br />Company’s vision<br />Project Context<br />Commitments, Business Plan, Internal & External Goals, Culture<br />Team A<br />Function A<br />Manager<br />Team B<br />Function B<br />3rd Party Vendors<br />Documentation, External Interfaces<br />Technology, Innovation, Culture<br />Project Ecosystem<br />
  32. 32. SWDevelopment Teams NW<br />
  33. 33. Providing a Vision for the Proejct<br />Project leaders must provide a vision for the members of the project so that each individual understands his or her contribution to that vision. <br />The vision must be defined according to the strategic obligations of the organization. <br />The vision describes the project’s ecosystem<br />These strategic obligations are determined by what the organization has committed to provide for its customers in terms of value, what systems must be established and managed to provide that value, and how the functions and tasks interrelate in order to meet those strategic obligations.<br />29<br />
  34. 34. What is the New Paradigm?<br />The new paradigm is founded on the recognition that managers must focus on the following two tasks:<br />i) Continuously knowing what is valued and what would be of more value to the customers of their organization’s products and/or services, and<br />ii) managing the creation, providing, and continuous improvement of strategic organizational suprasystems which when used by members of the organization will produce that which is of value to customers and users.”<br />G. Harlan Carothers, Jr., 1988<br />30<br />
  35. 35. Suprasystem Owner’s Accountabilities<br />Articulate the purpose of the suprasystem<br />Understand the link of the suprasystem to the customer<br />Understand and explain the relationship to other suprasystems of the organization, to functions, to processes, and to the activities and tasks of individuals<br />Map out the suprasystem, and understand its inputs, outputs, decision processes and linkages<br />Document the suprasystem, and make sure that all who must work within it have the knowledge, ability, and authority to do what is needed for the customer<br />Develop (in cooperation with appropriate people) outcome and operations suprasystem Owner’s Accountabilities measures which enable diagnosis of the suprasystem for improvement opportunities, as well as monitoring<br />Align efforts and resources toward suprasystem improvement<br />The responsibility will continue over time. It is not a project assignment. It is a managerial accountability.<br /> William C. Parr<br />
  36. 36. When System Thinking will help<br />The problems are been around for long time (there is a “history”)<br />Existing multitude of “theories” to explain the cause of the problems<br />Problems are dynamic and complex – complicated, stubborn, overtime, oscillating (based on mental and cultural)<br />Require new approach<br />על פי: Goodman, Karash, Lannon, O’Reilly, Seville: <br />Designing a System Thinking Intervention<br />
  37. 37. Systemic analysis and intervention<br />Identify a problem to be solved by systemic thinking<br />Describe the problem using listing of behaviors, time axis events and potential causes<br />Graphical depiction of the problems integrated with the theoretical factors – the big picture<br />Spotting the right point for intervention<br />
  38. 38. Level of Intervention in a Project <br />The mindset, paradigms, attitudes infrastructure – their influence on project health, cultural issues, inter-relations with intrasystem. Example: highly praising heroic activities, “the customer is stupid”<br />The goals of the project – clear definition, alignment, agreement. Example: quality, customer satisfaction, TTM as additional goals<br />Self-organization – define pressure for change, self adjustments<br />על פי: D.H. Meadows: Places to Intervene in a System<br />
  39. 39. Level of Intervention in a Project (2) <br />Rules, procedure – rules of the games, constraints, rewards, right-wrong, technical or behavioral. Example: change management, Hierarchical rules, reporting<br />Information floes – presenting results, feedback. Example: Public advancement reporting as motivational factor<br />Control positive feedback loops – more brings more until self-destroy, identify and control growth. Example: Resources growth by customer demand<br />על פי: D.H. Meadows: Places to Intervene in a System<br />
  40. 40. Level of Intervention in a Project (3) <br />Control balancing feedback loops – goalactionmeasurementaction<br />Material stocks and flow – quantity against flow magnitude, stock as stabilizing buffer. Example: Stock of system requirements against the flow of developing them<br />Data, measurements, results – change data, change interpretation. Example: Change number of reported bugs, change bugs scaling<br />על פי: D.H. Meadows: Places to Intervene in a System<br />
  41. 41. Thank you<br />July 09<br />