Your SlideShare is downloading. ×
0
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Good Projects Gone Bad: an Introduction to Process Maturity
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Good Projects Gone Bad: an Introduction to Process Maturity

4,192

Published on

PowerPoint version of presentation at the American Association of Museums. See related text version with references and footnotes.

PowerPoint version of presentation at the American Association of Museums. See related text version with references and footnotes.

Published in: Technology, Business
3 Comments
11 Likes
Statistics
Notes
No Downloads
Views
Total Views
4,192
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
411
Comments
3
Likes
11
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Transcript

    • 1. Good Project Gone Bad: Planning, Managing and Delivering Complex Technology Projects 1. Initial 2. Managed 3. Defined 4. Quantitatively Managed 5. Optimizing
    • 2. Good Project Gone Bad: Planning, Managing and Delivering Complex Technology Projects Michael Edson Director, Web and New Media Strategy Smithsonian Institution Nik Honeysett Head of Administration J. Paul Getty Museum AAM Annual Conference Monday, Apr 28, 2008 9:00 AM-10:15 AM
    • 3. Introduction Note See related text version of this show with links and footnotes
    • 4. “ a large but unknowable proportion of businesses fail pursuing nearly perfect strategies.” -- Peter Jones We Tried to Warn You Boxes and Arrows
    • 5.
      • “ Good companies tell stories of success, but great companies also tell stories of past failures to avoid repeating them.”
        • Christian Stadler The 4 Principles of Enduring Success Harvard Business Review
    • 6. The World Has Changed
      • “ Twenty years from now we’ll look back and say this was the embryonic period. The Web is only going to get more revolutionary”
      • --Tim Berners-Lee, 2006
    • 7. Introduction to Process Maturity Good Project Gone Bad: Planning, Managing and Delivering Complex Technology Projects Michael Edson Director, Web and New Media Strategy Smithsonian Institution [email_address]
    • 8.  
    • 9. www.si.edu
    • 10. Projects in Trouble
      • “ As systems become increasingly complex, successful software development becomes increasingly difficult. Most major system developments are fraught with cost, schedule, and performance shortfalls. We have repeatedly reported on costs rising by millions of dollars, schedule delays of not months but years, and multibillion-dollar systems that don’t perform as envisioned.”
      • --US General Services Administration, 1992
    • 11. Projects in Trouble
      • “ As systems become increasingly complex, successful software development becomes increasingly difficult. Most major system developments are fraught with cost, schedule, and performance shortfalls. We have repeatedly reported on costs rising by millions of dollars, schedule delays of not months but years, and multibillion-dollar systems that don’t perform as envisioned.”
      • --US General Services Administration, 1992
    • 12. AAM Accreditation
    • 13.  
    • 14. Capability Maturity Model
      • 1. Initial – Processes, if they are defined at all, are ad hoc. Successes depend on individual heroics and are generally not repeatable.
      • 2. Managed – Basic project management practices are established and the discipline is in place to repeat earlier successes with similar projects.
      • 3. Defined – Processes are documented and standardized and all projects use approved, tailored versions of the standard processes.
      • 4. Quantitatively Managed – The performance of processes and the quality of end-products are managed with quantitative measurement and analysis.
      • 5. Optimizing – Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas.
    • 15. Capability Maturity Model 1. Initial 2. Managed 3. Defined 4. Quantitatively Managed 5. Optimizing
    • 16. Understanding the levels Handout (and next slides) Level 1. Level 2. Level 3. Level 4. Level 5. People Success depends on individual heroics “ Fire fighting” is a way of life Relationships between disciplines are uncoordinated, perhaps even adversarial Success depends on individuals Commitments are understood and managed People are trained Project groups work together, perhaps as an integrated team Training is planned and provided according to roles Strong sense of teamwork exists within each project Strong sense of teamwork exists across the organization. Everyone is involved in process improvement Processes Few stable processes exist or are used “ Just do it!” At the individual project level, documented and stable estimating, planning and commitment processes are used Problems are recognized and corrected as they occur Integrated management and engineering (how things get built) processes are used across the organization Problems are anticipated and prevented, or their impacts are minimized Processes are quantitatively understood and stabilized Sources of individual problems are understood and eliminated Processes are continuously and systematically improved. Common sources of problems are understood and eliminated Measurement Data collection and analysis are ad hoc Planning and management data used by individual projects Data are collected and used in all defined processes Data are systematically shared across projects Data definition and collection are standardized across the organization Data are used to understand work processes quantitatively and stabilize them Data are used to evaluate and select process improvements Technology Introduction of new technology is risky Technology supports established, stable activities New technologies are evaluated on a qualitative basis New technologies are evaluated on a quantitative basis New technologies are proactively pursued and deployed
    • 17. Understanding the levels People Processes Measurement Technology 1 2 3 4 5
    • 18. Understanding the levels People Processes Measurement Technology 1 2 3 4 5 Success depends on individual heroics
    • 19. Understanding the levels People Processes Measurement Technology 1 2 3 4 5 “ Fire fighting” is a way of life
    • 20. Understanding the levels People Processes Measurement Technology 1 2 3 4 5 Relationships between disciplines are uncoordinated, perhaps even adversarial
    • 21. Understanding the levels People Processes Measurement Technology 1 2 3 4 5 Success depends on individuals Commitments are understood and managed People are trained
    • 22. Understanding the levels People Processes Measurement Technology 1 2 3 4 5 Project groups work together, perhaps as an integrated team Training is planned and provided according to rolesv
    • 23. Understanding the levels People Processes Measurement Technology 1 2 3 4 5 Strong sense of teamwork exists within each project
    • 24. Understanding the levels People Processes Measurement Technology 1 2 3 4 5 Strong sense of teamwork exists across the organization Everyone is involved in process improvement
    • 25. Understanding the levels People Processes Measurement Technology 1 2 3 4 5
    • 26. Understanding the levels People Processes Measurement Technology 1 2 3 4 5 Few stable processes exist or are used “ Just do it!”
    • 27. Understanding the levels People Processes Measurement Technology 1 2 3 4 5 At the individual project level, documented and stable estimating, planning and commitment processes are used Problems are recognized and corrected as they occur
    • 28. Understanding the levels People Processes Measurement Technology 1 2 3 4 5 Integrated management and engineering processes (how things get built) are used across the organization Problems are anticipated and prevented, or their impacts are minimized
    • 29. Understanding the levels People Processes Measurement Technology 1 2 3 4 5 Processes are quantitatively understood and stabilized Sources of individual problems are understood and eliminated
    • 30. Understanding the levels People Processes Measurement Technology 1 2 3 4 5 Processes are continuously and systematically improved Common sources of problems are understood and eliminated
    • 31.  
    • 32. Using the model
    • 33.  
    • 34. Capability Maturity Model Figure out where you are? 1. Initial 2. Managed 3. Defined 4. Quantitatively Managed 5. Optimizing
    • 35. Capability Maturity Model Ratchet up gradually over time 1. Initial 2. Managed 3. Defined 4. Quantitatively Managed 5. Optimizing
    • 36. Capability Maturity Model Don’t skip steps 1. Initial 2. Managed 3. Defined 4. Quantitatively Managed 5. Optimizing
    • 37. Capability Maturity Model Don’t slip back! 1. Initial 2. Managed 3. Defined 4. Quantitatively Managed 5. Optimizing
    • 38. Capability Maturity Model Pick projects Appropriate For your level 1. Initial 2. Managed 3. Defined 4. Quantitatively Managed 5. Optimizing
    • 39.  
    • 40. Some Practical Ways to increase process maturity Best Practices
    • 41. Avoid Classic Mistakes Best Practices Rank Estimated Probability of Occurrence Classic Mistake Action to Take 1 68% Lack of content or source-code control Implement source-code control practices
    • 42. Avoid Classic Mistakes Best Practices Rank Estimated Probability of Occurrence Classic Mistake Action to Take 1 68% Lack of content or source-code control Implement source-code control practices 2 60% Failure to produce a design document Produce a design, Ex Post Facto, starting week of August 25th
    • 43. Avoid Classic Mistakes Best Practices Rank Estimated Probability of Occurrence Classic Mistake Action to Take 3 60% Lack of project management plan Project plan v 1.0 completed August 20th 4 60% Failure to maintain project visibility Project visibility addressed in project plan.
    • 44. Avoid Classic Mistakes Best Practices Rank Estimated Probability of Occurrence Classic Mistake Action to Take 5 60% Feature Creep Produce a design. Prioritize feature set. 6 58% Wasted time upstream The cow is already out of the barn on this one!
    • 45. Avoid Classic Mistakes Best Practices Rank Estimated Probability of Occurrence Classic Mistake Action to Take 7 57% Reliance on heroics to complete a project Define roles and responsibilities. Emphasize accurate estimation. Implement management controls to track progress and anticipate delays. 8 53% Friction within team Address proactively with team members and management.
    • 46. Avoid Classic Mistakes Best Practices Rank Estimated Probability of Occurrence Classic Mistake Action to Take 9 53% Failure to accurately estimate time and resources Related to lack of design. Having a project management plan should help. Managers must ensure staff accurately defines and estimates tasks. 10 50% Failure to define requirements up front create requirements doc Ex Post Facto.
    • 47.  
    • 48. Spiral Project Plan Design Build Test Evaluate Then plan next loop START Best Practices
    • 49.  
    • 50. Assign Roles and Responsibilities
      • Tasks that have clear owners are more likely to get done
      Best Practices
    • 51. Assign Roles and Responsibilities
      • Managerial Roles
        • Sponsor
          • Internal client(s) for whom we’re producing the project. Defines goals. Supervises Project Owner and provides resources and direction to Project Owner and team. Provides “head above the trees” perspective of overall effort.
      Best Practices
    • 52. Assign Roles and Responsibilities
      • Managerial Roles
        • Project Owner
          • Responsible for,
            • high level organization and execution of project.
            • requirements analysis
            • creative brief
            • interface with project sponsors
            • team selection
            • high-level definition project lifecycle
            • monitoring and periodic reviews of content/functionality over entire project lifecycle
            • Usually reports to the Project Management Team
      Best Practices
    • 53. Assign Roles and Responsibilities Make sure every role is assigned to a person Best Practices
    • 54.  
    • 55. Standardized Reporting Best Practices
    • 56. Standardized Reporting Best Practices
    • 57. Standardized Reporting Best Practices
    • 58. Standardized Reporting Best Practices
    • 59.  
    • 60. Governance
      • Purpose
      • The purpose of this form is to provide an overview of proposed objectives and production/maintenance lifecycles for new Web content. This form requires information needed to support the editorial decision-making process. A completed form serves as a contract between project sponsors, team members, and SAAM decision makers.
      Best Practices Review process for new sites
    • 61. Governance
      • Process
      • This section is written with the project manager/project leader in mind
      • Somebody generates an idea and you take ownership of it: you are the project leader. You discuss the idea with potential partners, team members, and SAAM management. You define a project and walk it through the approval process.
      • You discuss the idea/project at the SAAM Web Weekly, and (optionally) at the SAAM Web Quarterly.
      • If the idea passes through informal discussions you formalize the creative and management aspects of the project and fill out this form.
      • You present the project and this form to the SAAM Web Quarterly and lead a discussion. You can review simple projects via e-mail: more complex projects require a meeting of the Web Quarterly and may require several meetings.
      • The SAAM Web Quarterly approves the idea (or engages you in an iterative process of questions, comments and review) and makes a recommendation to the Director.
      • The Director approves the idea.
      • You begin the next stages of planning and execution.
      • From this point on project management is handled at a detailed level by a Project Management Plan.
      Best Practices Review process for new sites
    • 62. Governance
      • Process
      • This section is written with the project manager/project leader in mind
      • Somebody generates an idea and you take ownership of it: you are the project leader. You discuss the idea with potential partners, team members, and SAAM management. You define a project and walk it through the approval process.
      • You discuss the idea/project at the SAAM Web Weekly, and (optionally) at the SAAM Web Quarterly.
      • If the idea passes through informal discussions you formalize the creative and management aspects of the project and fill out this form.
      • You present the project and this form to the SAAM Web Quarterly and lead a discussion. You can review simple projects via e-mail: more complex projects require a meeting of the Web Quarterly and may require several meetings.
      • The SAAM Web Quarterly approves the idea (or engages you in an iterative process of questions, comments and review) and makes a recommendation to the Director.
      • The Director approves the idea.
      • You begin the next stages of planning and execution.
      • From this point on project management is handled at a detailed level by a Project Management Plan.
      What kinds of projects should use this process? It is hard to describe this categorically. We’ll be using common sense case-by-case. Best Practices Review process for new sites
    • 63. Governance
      • Details
      • Who will be leading this idea though the approval process?
      • Who will be the project sponsor?
      • Who will be the project owner?
      • What other project “roles” are defined?
      • What is the title of the idea?
      • Please give an overview of the idea as you would pitch it to the Director and the Web Quarterly.
      • What deadlines are associated with this idea?
      • What partners (internal or external) will be involved?
      • Please describe the 3-year lifecycle of this idea.
      • What staff resources will be required for the 3-year lifecycle?
      • What financial resources will be required for the 3-year lifecycle?
      • What technological resources will be required for the 3-year lifecycle?
      Best Practices Review process for new sites
    • 64. Governance
      • Details
      • Who will be leading this idea though the approval process?
      • Who will be the project sponsor?
      • Who will be the project owner?
      • What other project “roles” are defined?
      • What is the title of the idea?
      • Please give an overview of the idea as you would pitch it to the Director and the Web Quarterly.
      • What deadlines are associated with this idea?
      • What partners (internal or external) will be involved?
      • Please describe the 3-year lifecycle of this idea.
      • What staff resources will be required for the 3-year lifecycle?
      • What financial resources will be required for the 3-year lifecycle?
      • What technological resources will be required for the 3-year lifecycle?
      Who will be leading this idea though the approval process? Best Practices Review process for new sites
    • 65. Governance
      • Details
      • Who will be leading this idea though the approval process?
      • Who will be the project sponsor?
      • Who will be the project owner?
      • What other project “roles” are defined?
      • What is the title of the idea?
      • Please give an overview of the idea as you would pitch it to the Director and the Web Quarterly.
      • What deadlines are associated with this idea?
      • What partners (internal or external) will be involved?
      • Please describe the 3-year lifecycle of this idea.
      • What staff resources will be required for the 3-year lifecycle?
      • What financial resources will be required for the 3-year lifecycle?
      • What technological resources will be required for the 3-year lifecycle?
      Who will be the project sponsor? Best Practices Review process for new sites
    • 66. Governance
      • Details
      • Who will be leading this idea though the approval process?
      • Who will be the project sponsor?
      • Who will be the project owner?
      • What other project “roles” are defined?
      • What is the title of the idea?
      • Please give an overview of the idea as you would pitch it to the Director and the Web Quarterly.
      • What deadlines are associated with this idea?
      • What partners (internal or external) will be involved?
      • Please describe the 3-year lifecycle of this idea.
      • What staff resources will be required for the 3-year lifecycle?
      • What financial resources will be required for the 3-year lifecycle?
      • What technological resources will be required for the 3-year lifecycle?
      What staff resources will be required for the 3-year lifecycle? Best Practices Review process for new sites
    • 67. Governance
      • Details
      • Who will be leading this idea though the approval process?
      • Who will be the project sponsor?
      • Who will be the project owner?
      • What other project “roles” are defined?
      • What is the title of the idea?
      • Please give an overview of the idea as you would pitch it to the Director and the Web Quarterly.
      • What deadlines are associated with this idea?
      • What partners (internal or external) will be involved?
      • Please describe the 3-year lifecycle of this idea.
      • What staff resources will be required for the 3-year lifecycle?
      • What financial resources will be required for the 3-year lifecycle?
      • What technological resources will be required for the 3-year lifecycle?
      & etc… Best Practices Review process for new sites
    • 68.  
    • 69. Consequences and Phenomena
    • 70. Capability Maturity Mismatch
      • When you and your vendor have different capability maturity levels… there can be a disruptive shearing effect on project processes
      TEAM
    • 71. Capability Maturity Mismatch
      • When you and your vendor have different capability maturity levels… there can be a disruptive shearing effect on project processes
      TE AM
    • 72. Capability Maturity Mismatch
      • Vendors say they see
      • conflicting institutional voices/opinions (client doesn’t speak with one voice)
      • adversarial relationships (“I don’t feel like we’re on the same team”)
      • wrong people in key positions
      • unrealistic expectations
      • content-approval deadlines are not met
      • undefined decision-making processes
      • little or no measurement of key performance indicators
      • insufficient staffing for the task at hand
      • completed projects are not maintained after delivery
    • 73.  
    • 74. Governance and Control
      • “ Just Enough”
    • 75.  
    • 76. Lightweight Frameworks
      • Web 2.0 Design Patterns (O’Reilly)
          • The Long Tail
          • Data is the Next Intel Inside
          • Users Add Value
          • Network Effects by Default
          • Some Rights Reserved.
          • The Perpetual Beta
          • Cooperate, Don't Control
          • Software Above the Level of a Single Device
    • 77.  
    • 78. Real World Examples
      • Handheld Multimedia Guide
    • 79. Real World Examples
      • Handheld Multimedia Guide
      • Blog
    • 80. Real World Examples
      • Handheld Multimedia Guide
      • Blog
      • Findability project
    • 81.  
    • 82. What you can do
      • Monday
        • Discuss process maturity with your coworkers
        • Pick a process to measure and improve
        • Assign responsibility and go for it!
      • In 90 days
        • Look at the CMM levels and agree on two things you can do to eke your way up a notch
        • Establish a group to own the process improvement initiatives
        • Talk with your vendors about what you could do better
        • Use Roles and Responsibilities, standard reporting, classic mistake avoidance
        • Learn about Web 2.0 frameworks
        • Measure measure measure
    • 83.  
    • 84. The Road to Success Efficient-Development Town YOU ARE HERE Reference: McConnell, Steve Rapid Development, Taming Wild Software Schedules . Microsoft Press, 1996
    • 85. The Road to Success Efficient-Development Town YOU ARE HERE Reference: McConnell, Steve Rapid Development, Taming Wild Software Schedules . Microsoft Press, 1996
    • 86. The Road to Success Efficient-Development Town Reference: McConnell, Steve Rapid Development, Taming Wild Software Schedules . Microsoft Press, 1996
    • 87. The Road to Success Efficient-Development Town Reference: McConnell, Steve Rapid Development, Taming Wild Software Schedules . Microsoft Press, 1996
    • 88. The Road to Success Classic-Mistakes Town Efficient-Development Town Reference: McConnell, Steve Rapid Development, Taming Wild Software Schedules . Microsoft Press, 1996
    • 89. The Road to Success Classic-Mistakes Town High-Cost/Long-Schedule Town Efficient-Development Town Reference: McConnell, Steve Rapid Development, Taming Wild Software Schedules . Microsoft Press, 1996
    • 90. The Road to Success Classic-Mistakes Town High-Cost/Long-Schedule Town Sometimes-Predictable-Cost-and-Schedule Town Efficient-Development Town Reference: McConnell, Steve Rapid Development, Taming Wild Software Schedules . Microsoft Press, 1996
    • 91. The Road to Success Classic-Mistakes Town High-Cost/Long-Schedule Town Sometimes-Predictable-Cost-and-Schedule Town Predictable-Cost-and-Schedule Town Efficient-Development Town Reference: McConnell, Steve Rapid Development, Taming Wild Software Schedules . Microsoft Press, 1996
    • 92. The Road to Success Classic-Mistakes Town High-Cost/Long-Schedule Town Sometimes-Predictable-Cost-and-Schedule Town Predictable-Cost-and-Schedule Town Efficient-Development Town Reference: McConnell, Steve Rapid Development, Taming Wild Software Schedules . Microsoft Press, 1996
    • 93. The Road to Success Classic-Mistakes Town High-Cost/Long-Schedule Town Sometimes-Predictable-Cost-and-Schedule Town Predictable-Cost-and-Schedule Town Efficient-Development Town Specialization… Reference: McConnell, Steve Rapid Development, Taming Wild Software Schedules . Microsoft Press, 1996
    • 94. The Road to Success Classic-Mistakes Town High-Cost/Long-Schedule Town Sometimes-Predictable-Cost-and-Schedule Town Predictable-Cost-and-Schedule Town Efficient-Development Town Specialization… Most organizations are here… Reference: McConnell, Steve Rapid Development, Taming Wild Software Schedules . Microsoft Press, 1996
    • 95. The Road to Success Classic-Mistakes Town High-Cost/Long-Schedule Town Sometimes-Predictable-Cost-and-Schedule Town Predictable-Cost-and-Schedule Town Efficient-Development Town Specialization… To get here, use any effective practice whatsoever… BUT USE IT! Reference: McConnell, Steve Rapid Development, Taming Wild Software Schedules . Microsoft Press, 1996
    • 96. References
      • Carroll, Sean B. 2005. Endless Forms Most Beautiful: The New Science of Evo Devo. New York : Norton, 2005.
      • CMMI Project Team. 2007. CMMI for Acquisition, Version 1.2: Improving Processes for Acquiring Better Products and Services. Pittsburgh : Software Engineering Institute, Carnegie Mellon, 2007.
      • — . 2006. CMMI for Development, Version 1.2. Pittsburgh : Software Engineering Institute, Carnegie Mellon University, 2006.
      • Edson, Michael. 2006. Data Access Strategy. Museums and the Web: Conference Proceedings. [Online] 3 1, 2006. [Cited: 4 22, 2008.] http://www.archimuse.com/mw2006/papers/edson/edson.html.
      • General Accounting Office. 1992. IMTEC-93-13 Mission-Critical Systems: Defense Attempting to Address Major Software Challenges. [Online] 1992. [Cited: 4 22, 2008.] http://archive.gao.gov/d36t11/148399.pdf.
      • Hotle, Matthew. 2007. 'Just Enough Process' for Applications. ID Number: G00145561. s.l. : Gartner, Inc., 2007.
      • — . 2007. The Little Big Application Organization: How a Big Organization Can Still Remain Small. ID Number: G00146962. s.l. : Gartner, Inc., 2007.
      • — . 2008. The 'Seven Deadly Sins' of Application Governance. ID Number: G00155896. s.l. : Gartner, Inc., 2008.
      • Jones, Peter. 2008. We Tried To Warn You, Part 2: Failure is a matter of timing. Boxes and Arrows. [Online] 3 26, 2008. [Cited: 4 22, 2008.] http://www.boxesandarrows.com/view/we-tried-to-warn-you32.
      • Keen, Andrew. 2007. The Cult of the Amateur: How today's internet is killing our culture. New York : Doubleday, 2007.
      • Kopcho, Joanne and Hottle, Matthew. 2008. CMMI Remains the Standard for Software Process Frameworks. Article ID #G00156315. Gartner.com. [Online] 4 18, 2008. [Cited: 4 22, 2008.] http://gartner.com.
      • Leading Change: Why Transformation Efforts Fail. Kotter, John P. 1995. 1995, Harvard Business Review; Mar/Apr95, Vol. 73 Issue 2, pp. 59 - 67.
      • McConnell, Steve. 1996. Rapid Development: Taming Wild Software Schedules. Redmond : Microsoft Press, 1996.
      • O'Reilly, Tim. 2005. Web 2.0: Design Patterns and Business Models for the Next Generation of Software. O'Reilly.com. [Online] 9 30, 2005. [Cited: 4 24, 2008.] http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html.
      • 2007. Universal Music CEO Doug Morris Speaks, Recording Industry in Even Deeper Shit Than We Thought. Aprapos of Nothing. [Online] 11 26, 2007. [Cited: 4 22, 2008.] http://nymag.com/daily/entertainment/2007/11/universal_music_ceo_doug_morris.html accessed 4/19/2008.
      • 2007. Universal's CEO Once Called iPod Users Thieves. Now He's Giving Songs Away. Wired.com. [Online] 11 27, 2007. [Cited: 4 22, 2008.] http://www.wired.com/entertainment/music/magazine/15-12/mf_morris.
      • Vivendi Board Biography of Doug Morris. [Online] [Cited: 4 22, 2008.] http://www.vivendi.com/corp/en/governance/dir_morris.php.
    • 97. Good Project Gone Bad: Planning, Managing and Delivering Complex Technology Projects Michael Edson Director, Web and New Media Strategy Smithsonian Institution Nik Honeysett Head of Administration J. Paul Getty Museum AAM Annual Conference Monday, Apr 28, 2008 9:00 AM-10:15 AM

    ×