As cited by Gartner, project failure rates are not improving based on a combined set of anecdotal and survey data, it seems that people believe projects are continuing to fall short of their goals:

• 82% of employees within companies with significant organization wide projects under way believe those projects will fail
• 78% believe they are working on a “doomed” project
• 90% knew early on that the project would likely fall short of the objectives
• 81% believe it is impossible to approach the failing project’s key decision-maker 

And they are usually right….

I’ve always been drawn to activities that stress team interaction over individual achievement.  Maybe that’s why application development appeals to me.  Success relies on integration of diverse skill sets and perspectives.  Project failure often results from failure of one or more specialists to fully integrate into the team.  Projects exceed expectations often because individuals subsume skills and achievements in support of team efforts. Maybe that’s why Adrian Cho’s “Jazz Process” piqued my interest.

Success!  The day has finally arrived to implement your technology project and, as the project manager, you are feeling good.  You mentally review the highlights of the presentation you’re planning to give to the project sponsor:

• Scope – all requirements have been met and tested, and everything works as designed.  Check.
• Schedule – the Go Live Date has been hit.  Check. 
• Budget (Cost) – an even better story, since you’re 5% under.  Check plus. 

You deliver your presentation, which goes well - the project team, immediate project stakeholders, and project sponsor are all pleased.   

And then, it happens -- user resistance.  Not all at once, and not necessarily too loudly at first or even communicated directly to the project team, but users are not happy about the launch of the new system, and complaints are growing.  The talk at the water cooler is that the project is a fa

The Richmond SPIN group recently hosted a workshop entitled “Oil and Water” that invited Agile Richmond to discuss how Agile methodology does or does not align with the Project Management Institute (PMI) Project Management Body of Knowledge (PMBOK).  As someone working on an Agile project, studying for my PMP certification, and having a waterfall development background, I was intrigued to participate in an open forum for Agile and PMBOK practitioners to discuss if/how both are used together in the real world.

At first glance, it may seem that there is no need to compare Agile to the PMBOK.  One is an approach to software development (see the Agile Manifesto) while the other is a set of project management best practices.

"Our goals can only be reached through a vehicle of a plan, in which we must fervently believe, and upon which we must vigorously act. There is no other route to success." - Pablo Picasso

It is an old story: about 30% of IT application projects succeed, 45% are "challenged," and the other quarter fail altogether.   That's the consistent result over the years of the Standish Group Study of Project Outcomes.  Jorge Dominguez, here, displays a chart of the remarkably similar results since 1994.  Not a pretty picture, right?  Some question the validity of the Standish studies, but Scott Ambler parallels the Standish story in a recent Dr Dobbs column called "Lies, Great Lies, and Software Development Project Plans," which itemizes the strategies commonly used by IT project managers to "stay out of trouble" when schedule/budget results don't match initial estimates.  For example, "18% change the original schedule to reflect the actual results".

When a project is hurried through requirements, defects are found, or the landscape changes around the project, a request is made to change the original requirements. This process in most projects is referred to as ‘Change Control’.

In most situations the focus of the Change Control process is to analyze the impact of a requirement change on your triple constraint (scope, schedule, budget) and gain the necessary approval to move forward with the requirement change.  What often goes unnoticed is the hidden cost the process of change control can bring to your project if not well managed.

Need uber-guru types who are willing to challenge the existing groupthink on design and architecture, especially on TDD and emergent design and pair programming anti-pattern” – job post at Monster.com 2/9/2010

I stumbled upon that quote following links on the role of the architect on an agile project. Maybe one important role of the architect is to help the team avoid groupthink.

Every year Gartner conducts a survey within the CIO community and 57% of the 1527 CIOs surveyed in the year 2008 identified "improving business processes" as one of the top five business expectations.  In fact, it has been the No.

In a recent very thoughtful post on data quality, Paul Erb plays out an analogy comparing data users with Don Quixote and data quality professionals with Sancho Panza, then reverses the analogy to cleverly coin the “Sancho Panza” test of data quality professionals.  He encourages data quality professionals promoting the critical role of data quality to apply a what would Sancho say test to ensure tha

In a new post at Insurance Networking News Ara Trembly provides a balanced perspective on IT/business misalignment (Business/IT Misalignment: Whose Responsibility?).  He describes the problem as cultural, more amenable to relational than management solutions.    His conclusion sums it up: “Take a geek/suit to lunch today!”