Child pages
  • Agile Project Management, Academic Impressions
Skip to end of metadata
Go to start of metadata

Using Agile IT Project Management to Improve Business Processes (Slide 1)

Patrick Masson, Chief Technology Officer
UmassOnline, University of Massachusetts
Office of the President

Ken Udas, Chief Executive Officer
UmassOnline, University of Massachusetts
Office of the President

About UMassOnline (Slide 2)

  • The online education consortium of the University of Massachusetts’ five campus system: Amherst, Boston, Dartmouth, Lowell and the Medical School in Worcester
  • Established in 2001 to serve community educational needs and increase access to a quality, affordable and internationally recognized UMass education
  • Currently supports 100 undergraduate and graduate degree and certificate programs in disciplines for which the University is best known: liberal arts, education, business and management, IT, nursing / public health, psychology and many more
  • In FY10, generated 45,815 enrollments and $56m in revenues, of which 90% remain on campus to fund campus development
  • Staff of 12 provides global marketing, technology support, and other support and services for online learning programs developed by the university’s five campuses.

Agenda (Slide 3)

The goal is to introduce some of the common issues raised during the project design and development process that have been identified as barriers to success and offer Agile methods which specifically address these issues.


Context: Why Do Projects Fail? (Slide 4)

Why do some IT projects fail while others succeed?

EDUCAUSE CIO Listserv Cloud (5)

The CHAOS Report (1994 - 2009) (6)

The Standish Group's CHAOS Report measures project failures in the IT industry.

  • Successful projects are delivered on time, on budget, with required features and functions
  • Challenged projects where late, over budget, and/or included less than the required features and functions
  • Failed projects were those that were canceled prior to completion or delivered and never used


Year 1994

Year 1996

Year 1998

Year 2000

Year 2002

Year 2004

Year 2006

Year 2009




























The Rise and Fall of the Chaos Report Figures (2010) (7)

In 1994, Standish published the Chaos report that showed a shocking 16 percent project success. This and renewed figures by Standish are often used to indicate that project management of application software development is in trouble. However, Standish's definitions have four major problems.

  • First, they're misleading because they're based solely on estimation accuracy of cost, time, and functionality.
  • Second, their estimation accuracy measure is one-sided, leading to unrealistic success rates.
  • Third, steering on their definitions perverts good estimation practice.
  • Fourth, the resulting figures are meaningless because they average numbers with an unknown bias, numbers that are introduced by different underlying estimation processes.

The authors of this article applied Standish's definitions to their own extensive data consisting of 5,457 forecasts of 1,211 real-world projects, totaling hundreds of millions of Euros. The Standish figures didn't reflect the reality of the case studies at all.

(Eveleens, J. Laurenz, and Chris Verhoef. "The Rise and Fall of the Chaos Report Figures." IEEE Software 27.1 (2010): 30-36. Print

The OASIG Study (1991) (8)

"7 in 10 Projects Fail in Some Respect"

Conducted in the UK among 45 experts from universities and consultancies.

Reasons for project failure:

  • The extent to which new systems are delivered on time and within budget
  • The fact that the new technology investment has been abandoned
  • The extent to which the new systems met expectations and gave value for money.

Causes of project failure:

  • Lack of attention to the human and organizational aspects of IT
  • Poor project management
  • Poor articulation of user requirements
  • Inadequate attention to business needs and goals.
  • Failure to involve users appropriately.

(As reported by IT Cortex,

The KPMG Canada Survey (1997) (9)

"Over 61% of the Projects Analyzed Were Deemed to have Failed"

This study, conducted by KPMG Canada (176 out of 1450 respondents).

Causes of project failure:

  • Specifically, inadequate risk management and a weak project plan.
  • The need for the system should be justified in ways that relate directly to the organization's business needs.
  • Lack of top management involvement and support
  • Projects fail more often because of schedule overruns than budget overruns.
  • Many projects fail because they use new or unproven technology.
  • Poor estimates or weak definitions of requirements at the project planning stage also contribute to project failure.
  • Projects can run into trouble due to the vendors' inability to meet commitments.
  • 60% of the failed projects were planned to take less than one year to complete.

(As reported by IT Cortex,

The Conference Board Survey (2001) (10)

"40% of Projects Failed to Achieve Their Business Case"

Survey interviewed executives at 117 companies that attempted ERP implementations.

  • 40% of the projects failed to achieve their business case within one year of going live
  • The 60% of companies that did achieve benefits said that achievement took six months longer than expected.
    • 34% were very “satisfied.”
    • 58% were “somewhat satisfied,”
    • 8% were unhappy with what they got.
  • Implementation costs were found to average 25% over budget,
  • Supports costs were underestimated for the year following implementation by an average of 20%

(As reported by IT Cortex,

The Robbins-joy-ya Survey (2001) (11)

"51% Viewed Their ERP Implementations as Unsuccessful"

232 survey respondents spanning multiple industries including government, Information Technology, communications, financial, utilities, and healthcare. A total of 36 % of the companies surveyed had, or were in the process of, implementing an ERP system.

Key Findings

  • 51% viewed their ERP implementation as unsuccessful
  • 46% of the participants noted that while their organization had an ERP system in place, or was implementing a system, they did not feel their organization understood how to use the system to improve the way they conduct business.
  • 56% of survey respondents noted their organization has a program management office (PMO) in place, and of these respondents, only 36 % felt their ERP implementation was unsuccessful

(As reported by IT Cortex,

A-va-nod Report (2007) (12)

"40% of Businesses Experienced Project Failure Between 2004 and 2006"

Avanade interviewed IT and operations managers from 102 companies, each supporting over 10,000 users.

  • 40% of businesses experienced project failure between 2004 and 2006

Causes cited for failures

  • 66% Poor system specification
  • 51% Lack of understanding between IT and business departments
  • 49% technology selection

(Kelly, Neon. "High Failure Rate Hits IT Projects." Computing. Incisive Financial Publishing Limited, 20 Aug. 2007. Web. 17 July 2010. <>.)

CRM failure rates: 2001-2009 (13)

  • 2001 Gartner Group: 50%
  • 2002 Butler Group: 70%
  • 2002 Selling Power, CSO Forum: 69.3%
  • 2005 AMR Research: 18%
  • 2006 AMR Research: 31%
  • 2007 AMR Research: 29%
  • 2007 Economist Intelligence Unit: 56%
  • 2009 Forrester Research: 47%

(Krigsman, Michael. "CRM Failure Rates: 2001-2009." Technology News, Analysis, Comments and Product Reviews for IT Professionals. ZDNet, 3 Aug. 2009. Web. 17 July 2010. <>.)

Causes for Project Failure (14)

Standish Group (1994) (15)

Reasons often cited for failure focus on poor design/planning during initial project phases, and an inability to control development.

IEEE (2005) (16)

Causes of project failure

  • Unrealistic or unarticulated project goals
  • Inaccurate estimates of needed resources
  • Badly defined system requirements
  • Poor reporting of the project's status
  • Unmanaged risks
  • Poor communication among customers, developers, and users
  • Use of immature technology
  • Inability to handle the project's complexity
  • Sloppy development practices
  • Poor project management
  • Stakeholder politics
  • Commercial pressures

(Charette, Robert N. "Why Software Fails." IEEE Spectrum Online. IEEE, Sept. 2005. Web. 17 July 2010. <>.)

UK Office of Government Commerce (2005) (17)

1. Lack of clear links between the project and the organization's key strategic priorities, including agreed measures of success.
2. Lack of clear senior management and Ministerial ownership and leadership.
3. Lack of effective engagement with stakeholders.
4. Lack of skills and proven approach to project management and risk management.
5. Too little attention to breaking development and implementation into manageable steps.
6. Evaluation of proposals driven by initial price rather than long-term value for money (especially securing delivery of business benefits).
7. Lack of understanding of, and contact with the supply industry at senior levels in the organization.
8. Lack of effective project team integration between clients, the supplier team and the supply chain.

(United Kingdom. Office of HM Treasury. Office of Government Commerce. Common Causes of Project Failure. By OGC. London: Office of Government Commerce, 2005. Print)

CIO Insight (2008) (18)

Causes of project failure

  • 30% Business needs change
  • 23% Does not deliver as promised
  • 14% No longer a priority
  • 13% Exceeds Budget
  • 07% Does Not Support Business Strategy

(Editors. "Why IT Projects Get Killed." CIO Insight. Ziff Davis Enterprise Holdings Inc. Web. 17 July 2010. <>.)

CIO Insight (2010) (19)

Causes of project failure:

  • Lack of user involvement
  • Unrealistic timetables
  • Poor requirements
  • Scope creep
  • Lack of executive support
  • Poor testing

(McCafferty, Dennis. "Why IT Projects Fail." CIO Insight. Ziff Davis Enterprise Holdings Inc., 10 June 2010. Web. 17 July 2010. <>.)

  • See STC2008 file
  • First Person Account (Example)

Causes for Failure Cloud (20)

Again... Why do projects fail? (21 - 22)

Why do projects fail?
Why do projects get started

Making the Case: PLANNING VS. PRINCIPLES (23)

Overview of APM

Agile project management offers an evolving set of values that guide principles and practice that are intended to support organic emergence within an organization. It really is an effort to create an environment that supports and enables behaviors that are conducive to change that naturally reduces risk associated with change.

Differences Between Agile and Traditional Project Management, It is in the Planning

Define Success... (24)

How well a project adheres to the plan.
- or -
The delivered business value.

Traditional Front-loaded Approaches

Agile Project Management (APM) is a stark departure from traditional front-loaded project management processes, where success often hinges on the ability to identify all of the system's needs before development begins. The fundamental difference between front-loaded and lightweight approaches used in APM boils down to planning vs. practice.

Front-loaded project management (such as Prince2, PMI’s PMBOK, or processes based on the Software Engineering Institutes's Capability Maturity Model) starts out with a heavy investment in 'planning.' Needs analysis, requirements gathering, gap analysis, resourcing, etc. all take place before development begins and are expected to remain consistent: an “engineering process.”

Planning is emphasized to mitigate risk and the key to successful technology development. Rigid procedures are needed to regulate change...

  • Hierarchical organizational structures are means of establishing order
  • Increased control results in increased order
  • Organizations/processes must be rigid and static hierarchies
  • Employees are interchangeable “parts” in the organizational “machine”
  • Problems are solved primarily through reductionist task breakdown and allocation
  • Projects and risks are adequately predictable to be managed through complex up-front planning
  • Changes are discouraged and may result in financial penalties.
  • Success in front-loaded projects is often defined by how well a project adheres to the plan, not on the quality of the work or the value of the finished project.

For Example, PMI Planning (25)

  • Develop a project planCreate a scope statement
  • Create a Work Breakdown Schedule
  • Create an activity list
  • Construct a network diagram
  • Develop activity duration estimates
  • Identify critical path(s)
  • Develop a project schedule
  • Determine resource requirements
  • Estimate project costs
  • Establish a cost baseline
  • Create a quality management plan
  • Document team roles & responsibilities
  • Assign project staff
  • Create a communication management plan
  • Create a risk management plan
  • Identify project risks and triggers
  • Perform qualitative & quantitative analysis
  • Develop a risk response plan
  • Prepare a statement of work
  • Prepare a procurement document

In contrast... Lightweight Approaches (26)

  • Lightweight approaches, such as APM, do not attempt to plan for the entire project, but rather provide practices for undertaking tasks as they are identified.
  • APM addresses needs for which there is evidence for implementation, rather than perceived or anticipated need.
  • Light-weight approaches accept that change will occur based on new information, technologies, etc.
  • This is why lightweight management practices are sometimes called evidence or event-based processes.
  • APM practitioners argue that there are no new projects. Rather new systems or services are simply extensions of the organization's current scope of services.
  • Small iterations, executed as the environment demands, results in a broader set of services/systems and greater usability among the campus community.
  • Risk is lessened by building upon existing systems that extend current features and functionality.


Agile Project Management allows existing business processes to be modified and new business processes to be developed at the same pace as the user can articulate them.

  • Jim Highsmith,
    Signatory, Manifesto for Agile Software Development
    Agile Project Management, 2004

Why this goal? (27)

Agile practices are based on the belief that neither the customers nor the developers have full knowledge in the beginning and that the important consideration is to have practices that will allow both to learn and evolve as that knowledge is gained---without ongoing recrimination.

  • Jim Highsmith,
    Signatory, Manifesto for Agile Software Development
    ”Agile Software Development Ecosystems” 2002

Conceptual Example, Two ways to Build a Pyramid (28-38)

Practical Example, Two ways to Implement SSO (39)

What Version of Google are you running? (40)

Versionlessness (41)

Google is “versionless” and further, does not have a pre-defined vision for future development/products.

We don’t have a traditional strategy process_, planning process like you’d find in traditional technical companies. It allows us to innovate very, very quickly, which I think is a real strength of the   company.”_

  • Eric Schmidt

You Have To Listen To People (42)

“You have to have a set of *_necessary conditions_* _for innovation to occur.”_

“To start with, you have to listen to people."

  • Eric Schmidt

UC Irvine (43-47)

At the University of California at Irvine, when they first built its campus, they just planted grass. Then they waited a year and looked at where people had made paths in the grass and built the side walks there.

  • Larry Wall

Relevant Example...

Traditional: Initiatives may not be rooted in existing services. Therefore their development may require staff, skills, or infrastructure not currently available within the IT department. This is a huge risk as there is no one who can accurately assess the departments ability at successfully implement the initiative. Interestingly, because the staff will need to learn and implement many of the critical technologies required to implement the initiative, time frames and total costs will be same as in the evolutionary approach. Again, however, because development will focus on discovery rather than application, it can be presumed that costs, time and overall, risk, will increase beyond the comfortability of senior management, end-users and your own department.

Agile: Feedback from users add functionality through time. The issues raised are based on real-world use of existing systems. Once the web page is up, users recognize the need for a uniform look and feel. Once more people are online, users need more than just content, they expect interactivity (forms). As more content and functionality comes online, users need content management Administrative content leads to academic content management, and so on. Each enhancement is only an incremental advancement in functionality and technology. The majority of staff, skills and infrastructure needed for the enhancement are already in place supporting the existing service/system.

Google Project Management/Development Process (48)

The philosophy is, try a bunch of ideas, refine them, and see what survives, says Marissa Mayer, the search giant's product-launch czar. “I'll start with a couple of core philosophies. The way you find really successful new innovation is to release five things and hope that one or two of them really take off. We like to put products out there early, see what users say about them, what additional features they'd like to see, and then build those out.”

  • “Inside Google's New-Product Process,” BusinessWeek, June, 2006

“The philosophy is, *_try a bunch of ideas, refine them, and see what survives.{*}”_

_“The way you find really successful new innovation is to  release five things and hope that one or two of them really take off. We like to put products out there early, see what users say about them, what additional features they'd like to see, and then build those out.”_

  • Marissa Mayer

Bloatware: Open Office (49)

Bloatware: Quotes (50)

Microsoft's brand-new version of Office for Mac OS X has been highly praised in reviews, but for many users it can't hold a candle to the 13-year-old Word 5.1.

Thirteen years on and many upgrades later, plenty of users are running Word 5.1 in OS X's Classic emulation environment.

  • Leander Kahney

Bloatware: MS Office 5.1 (51)

Goggle Services Illustration (52)

Look at all of these successful and recognizable services that Google currently provides.

Google "Failures" (53 - 57)

But not all of Google's service offerings were successfully received by the market.  Notice how Google's "failures" are approached within the context of their product management methodology.


“We don’t have a traditional strategy process, planning process like you’d find in traditional technical companies. It allows us to innovate very, very quickly, which I think is a real strength of the company.”

  • Eric Schmidt

Google's lightweight, iterative approach, focusing on small releases and rapid user feedback, "design through discovery,"  provides a model for organizations working within dynamic environments and with diverse stakeholders: much like your campus.

Implementation: Creating an Agile Environment (58)

Prairie House (59)

Incremental development that corresponds to the ability of a user to articulate their needs is an important part of the Agile approach.

Agile Manifesto (60)

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith,Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin,Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

Examples of Agile Values, Principles, and Objectives (61 - 73)

Value/Principle/Objective: Incremental Development
Example: Our highest priority is to satisfy the customer through early and continuous delivery of valuable services.

Value/Principle/Objective: Emergence & Courage
Example: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Value/Principle/Objective: Iteration
Example: Deliver working services frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Value/Principle/Objective: Continuous & Rapid Feedback
Example: Business people and developers must work together daily throughout the project.

Value/Principle/Objective: Transparency & Openness
Example: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Value/Principle/Objective: Communication & Collaboration
Example: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Value/Principle/Objective: Evidence-based
Example: Working services is the primary measure of progress.

Value/Principle/Objective: Humility
Example: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Value/Principle/Objective: Honesty
Example: Continuous attention to excellence and good design enhances agility.

Value/Principle/Objective: Simplicity
Example: Simplicity -- the art of maximizing the amount of work not done --is essential.

Value/Principle/Objective: Self-organizing Groups
Example: The best architectures, requirements, and designs emerge from self-organizing teams.

Value/Principle/Objective: Participation & Maturity
Example: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agility Maturity Model (74)

Impact: Stop Doing Projects (75)

Projects delivered "reasonably on time, on budget, to specification" (76)

  • Scott Ambler, Practice Leader Agile Development at IBM, 2008

Organizational Considerations (77)

  • “Agile is now a mainstream...”
  • “...require new or changed staffing and HR practices...”
  • “...agile development is more about culture than it is about process.”
    • David Norton, Gartner, Jun 27, 2010

Working with Agile (78)

  • “...the odds that you'll wind up on an Agile team in your next job is at least one in three, Agile has certainly gone mainstream.”
    • Tom Grant,  Forrester Research, January 25, 2010

Penn State World Campus Demonstrator Projects (79)

The Penn State, World Campus "Demonstrator Projects" focused principally on discovery and exploration.  This effort was influenced by a general recognition within the World Campus that our ideas were becoming old and we did not seem to be able to experiment effectively, express creativity, and behave in an innovative manner

Penn State World Campus Context (2008/2009)

  • World Campus is one of Penn State’s 25 Campuses
  • Responsible for Distance Education
  • Delivery Partner with Academic Units
  • 60+ Academic Degrees and Certificates
  • 24,000 Course enrollments
  • 40% Plus Growth Rate
  • Services include registration, academic advising, learning design, marketing, client development, educational technology, program management, etc.
  • Strong traditional “production” orientation

Conditions Impeding Experimentation (80)

  • A tradition of top-down hierarchical decision making processes
  • An emphasis on production efficiency(doing same things better)
  • A heavy planning process to avoid any disruptions to work flow
  • A large, resource intensive "task force" project management approach
  • Large organizational deployments and cut over for system migration
  • Insufficient levels of discovery and experimentation leading to change, because of the large investment and enforced rigidity made in any change process.

Overall Characteristics we were Trying to Achieve

We wanted the Demonstrators to be developed organically, which meant that they had to be:

  • Low Barrier
  • Low Cost
  • Low Risk

Methods/Practices (81)

  • Each Demonstrator is self-organizing (grassroots, not necessarily affiliated or "aligned in any formal way to a strategic plan )
  • Each Demonstrator meets specific needs (the owner needed to be able to articulate a need being met)
  • Each Demonstrator needed to take no longer then 90 days (keeping the projects manageable - we did not have budget for these other than time and minimal support, so we wanted to make sure that they did not unnecessarily drag out, demonstrators could build on themselves, forced reflection...)
  • Have no significant dependencies (This was to help ensure that folks would not get conservative or that unintended costs did not accrue.  Of course, if the Demonstrator went beyond its status and was implemented as a more traditional pilot or became production there would likely be dependencies.

Agile Methods

In practice, the Demonstrator Projects exhibited some agile behavior including:

  • Participation
  • Courage
  • Openness
  • Evidence-based
  • Self-organizing groups
  • Incremental Development
  • Simplicity
  • Decentralization

List of Demonstrator Projects (82-84)

  • Accessibility Demonstrator Project
  • Analytics Demonstrator Project
  • Building Community Demonstrator Project
  • Content Input/Output Demonstrator Project
  • Digital Asset Management System Demonstrator Project
  • ePortfolio Demonstrator Project
  • Faculty Advocacy Group for Web2.0 Demonstrator Project
  • Fluid Framework Demonstrator Project
  • Metadata Demonstrator Project
  • Occasionally Connected Course Demonstrator Project
  • Using Facebook as an Optional Delivery Platform for A WC Course
  • Utilizing Mobile Devices Demonstrator Project
  • World Campus on Facebook Demonstrator Project

Maturity Model (85)

Reflections / Lessons Learned (86)


  • Demonstrator "champions" do not have the time to pursue the idea given current levels of workload,
  • The time resources associated with coordinating and running the suite of demonstrator projects has not been allocated, so there is a lack of sustained advocacy and leadership,
  • The demonstrators operate in our "production" environment, and are subject to all of the barriers of  "doing business."


  • A small group will look through the proposals.
  • We will do our best to see which project meets the criteria for being a Demonstrator.
  • We will contact the Demonstrator sponsors, make comments on the Intranet, and get definition and try to determine if the proposal can be modified in ways that make sense and frame the project as a Demonstrator.
  • We may also ask others to join the review process.
  • Once "Demonstrators" are identified, we will apply other criteria to prioritize them and will work with the resource manages who will have to apply resources to the Projects.

You can see that our governance structure:

  • does not really reflect many elements that are characteristic of an agile and open organization.
  • For example, it was not decentralized, open, transparent, bottom-up, etc.
  • I believe that we missed an opportunity to really challenge the organization.

SUNY Delhi Agile Projects (87)

  • One of 64 campuses in the SUNY System
  • Business and Technology focus: Hospitality, Culinary Arts, Vet Sci, Nursing
  • Residential campus, 3000 FTE, 500 F/S
  • Located on the Western slope of the Catskills

SUNY Delhi Maturity Model (88)

SUNY Wiki: Agile Principles (89)

Analytics (90)

Feedback, Business Intelligence and Analytics leads to reduced development time as issues, errors and changes discovered and reported sooner.

Examples include:

Notifications (91)

Communication, continuous and rapid feedback

Smartboards (92)

Emergence, Evidence-based, Storytelling, Use Cases, Simplicity, Collaboration

Example (93)

ePorfolios (94)

Openness, Evidence-based, collaboration, Self-organizing, Transparency, Communications, Use Cases

Network Replacement (95)

Openness, Evidence-based, collaboration, Self-organizing, Transparency, Communication

Simplicity, Emergence, Incremental development,

Quote (96)

Example (97)

Incremental Development

Evaluations (98 - 99)

Honesty, Courage, Humility

Outcomes (100)

Thank You (101)

Repeat of Title (102)

Works Cited

  • Ambler, Scott W. "Surveys Exploring The Current State of Information Technology Practices." Ambysoft. Dr. Dobb's Journal, 2007-2010. Web. 25 July 2010. <>.
  • "Archives for CIO@LISTSERV.EDUCAUSE.EDU." Listserv. CIO Constituent Group. EDUCAUSE, 2010. Web. <>.
  • Beck, Kent, Et. Al. "Manifesto for Agile Software Development." Manifesto for Agile Software Development. 2001. Web. 25 July 2010. <>.
  • Beck, Kent, Et. Al. "Principles behind the Agile Manifesto." Manifesto for Agile Software Development. 2001. Web. 25 July 2010. <>.
  • Blechar, Mike. "Agile Methodologies: Hype or Reality?" Weblog post. Michael Blechar. Gartner Research Inc., 27 June 2010. Web. 25 July 2010.
  • Business Editors/High-Tech Writers. "Latest Standish Group CHAOS Report Shows Project Success Rates Have Improved by 50%." BNET, Business Services Industry. CBS Interactive, 25 Mar. 2003. Web. 17 July 2010. <>.
  • Charette, Robert N. "Why Software Fails." IEEE Spectrum Online. IEEE, Sept. 2005. Web. 17 July 2010. <>.
  • Dougherty, Alicia. "Gluing the Web Together: An Interview with Larry Wall." ZD Net. CBS Interactive, 17 Apr. 1998. Web. 25 July 2010.
  • Editors. "Project Management Institute (CAPM-PMP) - Wikibooks, Collection of Open-content Textbooks." Wikibooks. Wikimedia. Web. 26 July 2010. <>.
  • Editors. "Why IT Projects Get Killed." CIO Insight. Ziff Davis Enterprise Holdings Inc. Web. 17 July 2010. <>.
  • Elgin, Ben. "Inside Google's New-Product Process." Business Week. Bloomberg L.P., 30 June 2003. Web. 25 July 2010.
  • Eveleens, J. Laurenz, and Chris Verhoef. "The Rise and Fall of the Chaos Report Figures." IEEE Software 27.1 (2010): 30-36. Print.
  • Grant, Tom. "Agile Adoption Study Now Published." Web log post. Tom Grant's Blog. Forrester Research, Inc., 25 Jan. 2010. Web. 25 July 2010.
  • Highsmith, James A. Agile Software Development Ecosystems. Boston: Addison-Wesley, 2002. Print.
  • Highsmith, Jim. Agile Project Management Creating Innovative Products. Upper Saddle River, NJ: Addison-Wesley, 2009. Print.
  • Hof, Robert D. "How Google Fuels Its Idea Factory." Business Week. Bloomberg L.P., 28 Apr. 2008. Web. 25 July 2010.
  • IT Corxet. "The OASIG Survey (1995)." Failure Rate Statistics over IT Projects Failure Rate. IT Corxet. Web. 20 July 2010. <>.
  • Johnson, Jim, Karen D. Boucher, Kyle Connors, and James Robinson. "Collaborating on Project Success." Software Magazine. Wiesner Publishing, 26 Feb. 2001. Web. 17 July 2010. <>.
  • Kahney, Leander. "Word Refuseniks: Never Upgrade." Wired. Condé Nast Digital, 17 June 2004. Web. 25 July 2010.
  • Kelly, Neon. "High Failure Rate Hits IT Projects." Computing. Incisive Financial Publishing Limited, 20 Aug. 2007. Web. 17 July 2010.
  • Highsmith, Jim. Agile Project Management: Creating Innovative Products. Boston,Mass.;Munich[u.a.: Addison-Wesley, 2007. Print.<>.
  • Krigsman, Michael. "CRM Failure Rates: 2001-2009." Technology News, Analysis, Comments and Product Reviews for IT Professionals. ZDNet, 3 Aug. 2009. Web. 17 July 2010. <>.
  • Levinson, Meridith. "Recession Causes Rising IT Project Failure Rates." - Business Technology Leadership. CXO Media Inc., 18 June 2009. Web. 17 July 2010. <>.
  • Mayo-Smith, John. "Two Ways To Build A Pyramid." InformationWeek. 22 Oct. 2001. Web. 25 July 2010.
  • McCafferty, Dennis. "Why IT Projects Fail." CIO Insight. Ziff Davis Enterprise Holdings Inc., 10 June 2010. Web. 17 July 2010. <>.
  • Standish Group. The Chaos Report. Rep. Boston: Standish Group, 1994. Print.
  • Tony, Perkins. "About Google’s Eric Schmidt." Always On. Apr. 2003. Web. 25 July 2010.
  • United Kingdom. Office of HM Treasury. Office of Government Commerce. Common Causes of Project Failure. By OGC. London: Office of Government Commerce, 2005. Print.

Varney, Almon Clother. Our Homes and Their Adornments. Detroit, MI: J.C. Chilton &, 1882. Print


  1. Is it worth explicitly "tipping our hat" explicitly to the notion of larger organizational applications of agility and openness? 

    1. Anonymous

      When I originally proposed this webcast to the AI leadership, I included more explicitly in the target audience directors and project managers in campus/facilities planning units, in addition to those in IT shops, but the recommendation was that we focus more on IT project management stakeholders per se.  That said, I see no reason near the end of the agenda for you to point to "larger organizational applications," especially to the extent that IT project managers might become evangelists on their campuses.

  2. Nice content outline.  Would we like to have an example/illustration-based approch to addressing the content?

    1. Anonymous

      Definitely.  This, in fact, is critical in AI webcasts: regular, concrete examples from real/hypothetical projects.  Over a 90-minute webcast, attendees will get glassy-eyed and downright ornery if the content stays too much at a level of abstract principles.  One thought I had is that you use two different projects in which each of you played central roles (at Penn State World Campus/SUNY-Delhi/UMass Online) and thread those throughout the agenda, i.e., bringing in specifics from each project as they illustrate principles and lessons learned about APM under each of the main agenda bullets.  A further thought: Perhaps you could bring in THREE projects through the agenda: Two projects completed at your former institutions and one project underway at UMass Online that is benefitting from what you learned from the two previous projects.

      I'm glad to host a conference call between the three of us, whenever, if you think it would help.  - Peter

  3. Excellent sources.  I am sure that we can tease out a few third party illustrations for specific prinicples and practices as well as our first hand illustrations.