VDCL Recent Results

1,554 views
1,465 views

Published on

Show recent, preliminary results into project leadership practices that contribute to success of I.T.-intensive business projects.

Published in: Business, Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,554
On SlideShare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
25
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

VDCL Recent Results

  1. 1. Gezinus J. Hidding, Ph.D. Loyola University Chicago ghiddin@luc.edu, 312.915.7059 Joint research with John Nicholas, Ph.D. jnichol@luc.edu, 312.915.7060
  2. 2. Objective <ul><li>By the End of this Session: </li></ul><ul><li>You Will Understand How </li></ul><ul><li>Business Analysts </li></ul><ul><li>Can Contribute to Success </li></ul><ul><li>Of I.T.- Intensive Business Projects </li></ul><ul><li>This is YOUR Session: </li></ul><ul><ul><li>Feel Free to Interrupt Whenever </li></ul></ul>
  3. 3. Overview <ul><li>There Are (Still) Many (I.T.) Project Failures </li></ul><ul><li>Needed: A New Paradigm </li></ul><ul><li>for (I.T.) Project Management (P.M.) </li></ul><ul><ul><li>Value-Driven Change Leadership (VDCL) </li></ul></ul><ul><li>Our Empirical Research (Ongoing) </li></ul><ul><ul><li>Find Project Management Practices </li></ul></ul><ul><ul><li>Associated with Project Success or Failure </li></ul></ul><ul><li>Research Results To Date </li></ul><ul><ul><li>PMBOK/VDCL Success Factors </li></ul></ul><ul><ul><li>Observations That Are Striking (to Us) </li></ul></ul>
  4. 4. I.T. Project Failures: There Are (Still) Many <ul><li>Standish Group - Chaos 2006 </li></ul><ul><ul><li>19% of Projects Canceled before Completed </li></ul></ul><ul><ul><li>46% of Projects Over Budget, Late and/or Less Features </li></ul></ul><ul><ul><li>35% of Projects On Time, On Budget, as Specified </li></ul></ul><ul><li>Department of Defense Software Projects </li></ul><ul><ul><li>29% - Paid for, but not delivered </li></ul></ul><ul><ul><li>46% - Delivered, but not successfully used </li></ul></ul><ul><ul><li>20% - Used, but extensively reworked or abandoned </li></ul></ul><ul><ul><li>3% - Used after changes </li></ul></ul><ul><ul><li>2% - Used as delivered </li></ul></ul><ul><li>Diamond Consultants’ Digital IQ study </li></ul><ul><ul><li>43% of IT executives: </li></ul></ul><ul><ul><li>90% of projects meet initial expectations </li></ul></ul>See also: “Common Sense in Project Management” Paul Tedesco, Thomson Publishing, 2006.
  5. 5. Common Failure Factors <ul><li>Bad Project Planning </li></ul><ul><ul><li>Poor Specification of End-Item </li></ul></ul><ul><ul><li>Wrong Estimate of Cost/Resources </li></ul></ul><ul><li>Bad Project Management </li></ul><ul><ul><li>Bad Scope Management </li></ul></ul><ul><ul><li>Ineffective Change Control </li></ul></ul><ul><ul><li>Poor Issues Management </li></ul></ul><ul><li>Bad Monitoring & Control </li></ul><ul><ul><li>Projects up to 20 times more likely to escalate in terms of time and costs </li></ul></ul><ul><ul><li>(Mark Keil – Georgia State University) </li></ul></ul>
  6. 6. Cause: Wrong Success Measures <ul><li>If a Project Was: </li></ul><ul><li>“ Ahead of Schedule” and “Below Budget,” </li></ul><ul><ul><li>Was It Successful? </li></ul></ul><ul><li>“ Behind Schedule” and “Over Budget,” </li></ul><ul><ul><li>Was It a Failure? </li></ul></ul><ul><li>“ Ahead of Schedule” but “Over Budget,” </li></ul><ul><ul><li>What Is It? </li></ul></ul><ul><li>“ Behind Schedule” but “Under Budget,” </li></ul><ul><ul><li>What Is It? </li></ul></ul>
  7. 7. Root Cause: Traditional P.M. Paradigm <ul><li>The Traditional P.M. Paradigm Focuses On </li></ul><ul><li>Activities Being “On Schedule” and “Within Budget,” </li></ul><ul><li>Not on Value Added by the Delivered Products. </li></ul><ul><li>Planned Added </li></ul><ul><li>Value Value </li></ul><ul><li>Planned Delivered </li></ul><ul><li>Products Products </li></ul><ul><li>Activities </li></ul>“ Goal-Directed Project Management: Effective Techniques and Strategies”, Erling Andersen, Kristoffer Grude , Tor Haug, Kogan Page, 1995.
  8. 8. Needed: New Paradigm Value-Driven Change Leadership (VDCL) <ul><li>3 Key Aspects: </li></ul><ul><li>Change </li></ul><ul><li>Leadership </li></ul><ul><ul><li>based on </li></ul></ul><ul><li>Solution </li></ul><ul><li>Architecture </li></ul><ul><ul><li>towards </li></ul></ul><ul><li>Business </li></ul><ul><li>Value </li></ul>
  9. 9. Differences <ul><li>Traditional P.M. </li></ul><ul><li>Manage Administer </li></ul><ul><li>Activities </li></ul><ul><li>through </li></ul><ul><li>Phases </li></ul><ul><li>towards </li></ul><ul><li>On-Time/ Budget </li></ul><ul><li>based on </li></ul><ul><li>PERT Chart </li></ul><ul><li>VDCL </li></ul><ul><li>Lead </li></ul><ul><li>People </li></ul><ul><li>through </li></ul><ul><li>Releases </li></ul><ul><li>towards </li></ul><ul><li>Value (End results) </li></ul><ul><li>based on </li></ul><ul><li>Solution Architecture </li></ul>
  10. 10. Who Is Involved in VDCL? <ul><li>20 Seasoned I.T. Project Managers </li></ul><ul><li>With Average Experience of 20 years: </li></ul><ul><li>University faculty: with Practical Experience </li></ul><ul><li>Consultants: I.T. and Business </li></ul><ul><li>Project Managers: at Real Companies </li></ul><ul><li>I.T. Architects: of Large Systems </li></ul><ul><li>Vendors: of Software Tools </li></ul><ul><li>Authors: Books about Project Management </li></ul>
  11. 11. Our View: Projects Implement Strategy Through Change <ul><li>Strategy </li></ul><ul><li>Project </li></ul><ul><li> Change </li></ul>
  12. 12. Let’s Go Out There And Shift Some Paradigm! <ul><li>From: Pepper … and Salt, The Wall Street Journal </li></ul>
  13. 13. VDCL: Fundamental Principles <ul><li>“ There Are No I.T. Projects. </li></ul><ul><li>There Are Only Business Projects. </li></ul><ul><li>Some Have More I.T. than Others.” </li></ul><ul><li>Value-driven </li></ul><ul><ul><li>Value-added over Budget/Schedule </li></ul></ul><ul><li>Change Leadership </li></ul><ul><ul><li>Human Change over Repeated Activities </li></ul></ul><ul><li>Based on Architecture </li></ul><ul><ul><li>Business Solution over Architecture Framework </li></ul></ul>
  14. 14. Value - driven <ul><li>“ Firms Invest in I.T. to Create Value, Not Software.” </li></ul><ul><li>Value-added over </li></ul><ul><li>Budget/Schedule </li></ul><ul><li>Measuring Business Results over </li></ul><ul><li>Measuring Project Conformance </li></ul><ul><li>Managing the Business Case over </li></ul><ul><li>Abandoning the Business Case </li></ul><ul><li>Quantifying the Financial Impact of Risks over Identifying a List of Risks </li></ul>
  15. 15. B.A. “How To”: Manage Change Requests to Value <ul><li>Budget Schedule and Value </li></ul><ul><li>Change 1 . . . </li></ul><ul><li>Change 2 . . . </li></ul><ul><li>Change 3 . . . </li></ul><ul><li>Change 4 . . . </li></ul><ul><li>… </li></ul>
  16. 16. Change Leadership <ul><li>“ It’s the People, Stupid” </li></ul><ul><li>Human Change over </li></ul><ul><li>Repeated Activities </li></ul><ul><li>Changing Organizations over </li></ul><ul><li>Delivering Products </li></ul><ul><li>Improving Activities over </li></ul><ul><li>Repeating Activities </li></ul><ul><li>Developing Human Relations over </li></ul><ul><li>Interchanging Resources </li></ul>
  17. 17. “ The ‘Soft Stuff’ Is the ‘Hard Stuff’” <ul><li>Leadership </li></ul><ul><ul><li>Executive Support </li></ul></ul><ul><ul><li>Change Management </li></ul></ul><ul><ul><li>Assign Well-Suited Personnel </li></ul></ul><ul><li>Communication </li></ul><ul><ul><li>With Customer </li></ul></ul><ul><ul><li>With User </li></ul></ul><ul><ul><li>Within Management Hierarchy </li></ul></ul><ul><ul><li>Within Project Team </li></ul></ul><ul><li>Team Cohesion </li></ul><ul><ul><li>Commitment to Project/Goal and Team </li></ul></ul><ul><ul><li>Intercultural Issues </li></ul></ul><ul><ul><li>Conflict Management </li></ul></ul>
  18. 18. B.A. “How To”: Time to Learn from Others <ul><li>Learn from Customers: </li></ul><ul><li>How Can We Serve You Better? </li></ul><ul><li>Learn from Team Members: </li></ul><ul><li>How Can We Work Smarter? </li></ul><ul><li>Learn from Other Current Projects: </li></ul><ul><li>What Should We (Not) Do? </li></ul><ul><li>Learn from Previous Projects: </li></ul><ul><li>If You Had To Do It Over, </li></ul><ul><li>What Would You (Not) Do? </li></ul>
  19. 19. Based on Architecture <ul><li>“ Skyscrapers Are not Built Wall by Wall, </li></ul><ul><li>but Floor by Floor, around the Core.” </li></ul><ul><li>Business Solution over </li></ul><ul><li>Architecture Framework </li></ul><ul><li>Designing Business Solutions over </li></ul><ul><li>Debating Generic Frameworks </li></ul><ul><li>Releasing Frequently over </li></ul><ul><li>Releasing with One Big Bang </li></ul><ul><li>Flexible Architecture Alternatives over </li></ul><ul><li>One Architecture Design </li></ul>
  20. 20. Definition: Architecture Is Representation of Structure <ul><li>Architecture of Application/ Solution </li></ul><ul><ul><li>Representation Describing Structure of a Specific System: </li></ul></ul><ul><ul><ul><li>Configuration of Common Modules </li></ul></ul></ul><ul><ul><ul><li>Relations between Modules (I/O, Control) </li></ul></ul></ul><ul><ul><ul><li>Specific Syntax of Modules’ Interfaces </li></ul></ul></ul><ul><li>Specific Business Drivers Lead to a Specific Architecture </li></ul><ul><li>20% of the Code Drives 80% of the Requirements (20/80 rule) </li></ul>
  21. 21. Definition: Architecture Is Not Infrastructure <ul><li>Infrastructure Is a Supersystem Offering Common Functionalities to Be Used by the Application/ Solution </li></ul><ul><li>Structure Is Common Functionalities in the Application/ Solution </li></ul><ul><li>Infrastructure and Application/ Solution Both (Can) Have an Architecture </li></ul><ul><li>VDCL Is Agnostic about Development Method </li></ul><ul><ul><li>Calls for Explicit Attention to Architecture </li></ul></ul><ul><ul><li>Does Not Require a Particular Method </li></ul></ul>
  22. 22. B.A. “How To”: Prioritize What Is (Not) Essential? <ul><li>Which Objectives Are Essential? </li></ul><ul><li>Which Functionalities Are Essential? </li></ul><ul><li>Which Modules Are Essential? </li></ul><ul><li>What Can Be Delivered Sooner/Later? </li></ul>
  23. 23. VDCL Paradigm: Summary <ul><li>Decide How Much Value To Deliver When </li></ul><ul><li>Decide Which Deliverables Make Up Each Release </li></ul><ul><li>Plan Each Release As Usual (Schedule, Budget, …) </li></ul><ul><li>Manage Based On Results Achieved </li></ul><ul><li>Value Value Value Value ... </li></ul><ul><li>Architecture </li></ul><ul><li>Release Release Release ... </li></ul><ul><li>Activities Activities ... </li></ul><ul><li>Time </li></ul>
  24. 24. Empirical Research: Does VDCL Make a Difference? <ul><li>VDCL: </li></ul><ul><ul><li>Business Value </li></ul></ul><ul><ul><li>Change Leadership </li></ul></ul><ul><ul><li>Solution Architecture </li></ul></ul><ul><li>Project </li></ul><ul><li>PMBOK </li></ul><ul><ul><li>9 Knowledge Areas </li></ul></ul><ul><li>Success </li></ul><ul><li>Project Demographics </li></ul><ul><ul><li>Project </li></ul></ul><ul><ul><li>Project Manager </li></ul></ul><ul><ul><li>Organization </li></ul></ul>
  25. 25. Research Design <ul><li>Study Medium-Sized I.T. Projects </li></ul><ul><li>In Large(r) Chicago-based Organizations </li></ul><ul><ul><li>Sofar: Sixteen Projects in Seven Organizations </li></ul></ul><ul><ul><ul><li>Not enough yet for solid statistic analysis (e.g., PLS) </li></ul></ul></ul><ul><li>Per Company, Compare Projects Pair(s): </li></ul><ul><ul><li>Successful – Unsuccessful </li></ul></ul><ul><li>Structured Interviews </li></ul><ul><ul><li>Standard Questionnaire </li></ul></ul><ul><ul><ul><li>Secured IRB Approval </li></ul></ul></ul><ul><ul><li>Interview Project Manager </li></ul></ul>
  26. 26. Interview Questionnaire <ul><li>Organization Background </li></ul><ul><li>Project Background </li></ul><ul><li>Project Manager Background </li></ul><ul><li>Measures of Success/ Failure </li></ul><ul><li>PM Practices </li></ul><ul><ul><li>PMBOK </li></ul></ul><ul><ul><li>VDCL </li></ul></ul>
  27. 27. Sample Statements (on a 7-Point Scale Strongly Disagree – Strongly Agree) <ul><li>From the Perspective of the Organization’s Value Added (Taking into Account All Benefits and All Costs), </li></ul><ul><li>This Project Was a Success </li></ul><ul><li>From Beginning to End, The Business Case Was Kept Up-To-Date and the Project Stayed Focused on Achieving It. </li></ul><ul><li>The Project Plan Adequately Reflected </li></ul><ul><li>the End-Product’s Architecture. </li></ul><ul><li>From Beginning to End, The Project Focused on People Having to Change. </li></ul>
  28. 28. Non-parametric Analysis <ul><li>Project Pair 1 2 3 … n Correlation </li></ul><ul><li>PM Practice 1 + + + + Positive </li></ul><ul><li>PM Practice 2 + 0 0 - None </li></ul><ul><li>… </li></ul><ul><li>PM Practice n - - - - Negative </li></ul><ul><li>+/- When Practice Was Used More/Less </li></ul><ul><li>in Successful Project in Pair i </li></ul><ul><li>than in Less-Successful Project </li></ul>
  29. 29. Preliminary Results to Date: Correlation with Success <ul><li>PMBOK: </li></ul><ul><ul><li>(T1) Time Management </li></ul></ul><ul><ul><li>(S1) Scope Management </li></ul></ul><ul><ul><li>(Com1) Expectations Management </li></ul></ul><ul><li>VDCL: </li></ul><ul><ul><li>(V2) Keep Business Case Updated Throughout </li></ul></ul><ul><ul><li>(V3) All Stakeholders Agree on Project Purpose </li></ul></ul><ul><ul><li>(A) Project Plan Reflected Solution Architecture </li></ul></ul>
  30. 30. Keep Business Case Updated Throughout the Project <ul><li>Before Project Starts </li></ul><ul><ul><li>Clarify project purpose and success metrics </li></ul></ul><ul><ul><li>Evaluate alternatives </li></ul></ul><ul><li>During Project Implementation </li></ul><ul><ul><li>Evaluate change requests </li></ul></ul><ul><ul><li>Make trade-off decisions </li></ul></ul><ul><li>After Project Ends </li></ul><ul><ul><li>Analyze business value / project outcome </li></ul></ul>
  31. 31. All Stakeholders Agree on Project Purpose <ul><li>Reach Agreement and Understanding among Key Stakeholders </li></ul><ul><li>and All Project Participants </li></ul><ul><li>on the Project’s Value / Outcomes </li></ul><ul><li>and Clear Success Metrics </li></ul><ul><li>Give Project Participants a Personal Stake in the Project’s Success or Failure </li></ul>
  32. 32. Striking Observations <ul><li>Almost ALL Projects Overran </li></ul><ul><li>Schedule and Budget </li></ul><ul><ul><li>“ Successful” and “Unsuccessful” Projects Alike </li></ul></ul><ul><ul><li>But, Successful Projects Had Smaller Overruns </li></ul></ul><ul><li>Almost ALL Projects Do NOT Track: </li></ul><ul><li>- Employee Labor Hours </li></ul><ul><li>- Benefits </li></ul><ul><ul><ul><li>Neither During Development Nor After Delivery </li></ul></ul></ul><ul><li>Some “Failed” Projects Did Not Deliver due to Dependency on Larger Program </li></ul>
  33. 33. Discussion <ul><li>Questions? </li></ul><ul><li>Reactions? </li></ul><ul><li>Feedback? </li></ul><ul><li>Agreement? </li></ul><ul><li>Disagreement? </li></ul>
  34. 34. Preliminary Results to Date: No Correlation with Success <ul><li>PMBOK: </li></ul><ul><ul><li>(HR1) Human Resource Management </li></ul></ul><ul><li>VDCL: </li></ul><ul><ul><li>Negatively Correlated? </li></ul></ul><ul><ul><ul><li>(V5) Quantify Financial Impact of Combined Risks </li></ul></ul></ul><ul><ul><ul><li>(A3) Deliver in Multiple Releases </li></ul></ul></ul><ul><ul><ul><ul><li>Inadvertent Sample Bias? </li></ul></ul></ul></ul><ul><ul><ul><li>(P7) Project’s Riskiness (as Perceived at the Start) </li></ul></ul></ul>

×