Chaos Report Background

July 12, 2007

After my last post discussing the Standish Group someone brought to my attention an interview done by Deborah Hartman, an Editor at InfoQ, with Jim Johnson from the Standish Group. In the interview he explains the history of the research, the method and the role of Agile.  Read it here.  An interesting read considering the press the report gets everywhere.


We’re Making Headway

July 12, 2007

The textbook I have been using in the course the last 4 semesters, Information Technology Project Management, 4th Edition, Kathy Schwalbe, uses excerpts from the Standish Groups 2003 Chaos Report. Some of the data sited are cost overruns at a rate of 43%, which, while still quite large, are a marked improved from 189% (yes, you read one-eight-nine) in 1994. The dollar amount of IT projects in 2002 was $55 billion, which includes canceled projects overruns, compared to $140 billion in 1994.

If you look at the history of how successful projects are there is a dramatic improvement between 1994 and 1998 and then a slight improvement since then. I could never really put my finger on why this period caused such a dramatic improvement.

I always ask the students what they believe the reason for the improvement is between the mid 90’s and a few years ago. The following is a short list of what we usually come up with:

· Improved project management techniques

· Improved estimating and controlling techniques

· Shorter projects (not biting off too much at one time)

· Better developer methodologies

While a case can be made for all of these, it never really made me feel as if we had really come up with the reason for the improvement.

Well, maybe this is it. If you read here you will find one theory from the Founder and Chairman of the Standish Group, Jim Johnson. The dawn of the Internet and the type of development browser based systems were the catalyst for such a dramatic improvement. Need to think about this some, but you know… it makes sense.

In the coming semester I plan on using Zoho as a teaching aid for the students.  It is free for 1 project and being web based we can collaborate.  I discussed this type of tools in my other blog (which still overlaps in some ways with this blog but will eventually become solely a SW development blog) some tools and did a non comparison evaluation.

Here is an blog post to Zoho and where it is mentioned on how they keep a close eye on the blogosphere.  I can attest to that, they commented on my other blog thanking me!

 So, I will be getting back into the product and discussing it on and off in the blog here.  My earlier posts was a 3 part series (the 2nd looked at Basecamp which is an awesome product too) where I introduced the subject of Web based project management tools here and took a deeper look at Zoho Projects here.

Sweet Smell Of Success

July 10, 2007

Everyone has a different definition of what success means and most people have set goals in their own life on when they would say they have neared or achieved success. One question I will ask at some point in every class is

“How do you think you can define a project as success?”
(followed by some feigned look of contemplation)

“When the client pays!”
(followed by some slight looks of amusement from a small minority)

But, when is a project a success? I was reminded what a moving target project success can be when reading this blog entry. One definition is it is a success when a project meets time, cost and scope expectations (triple constraint) set out in the project definition phase. Another can be when the customer signs a project acceptance form signifying the project has met requirements. Another could be when the project has passed a rigorous form of QA and user testing and is running in its production environment.

I have had developers tell me that they worked on projects that were considered a success by their companies or the client but not by them. They didn’t implement the database interface the way they wanted or the user interface could have been implemented with the newest widget to make it look better. The answer to this is; get over it. You delivered software to a client who is happy. He paid for it, you didn’t. His opinion matter more than yours. Besides, the reasons you state the project were not a success have no effect on the world’s view of the projects successfulness. So, the project was a success.

However, being somewhat of a nebulous term and allowing considerable lee way in its definition I think there is not a definite answer. The answer lays in the fact the user and the developer must be on the same page, in almost every step of the project, on what success is and their definitions must be the same or very similar. The exact definition will change, become more refined, and each party must understand and be in agreement with the changes.

This is why I believe agile development really does help in achieving project success. Agile allows the team and client to experience small portions of success on the long road to the ultimate success. It is like passing mile markers on a long road trip.  In Agile we can correct when we stray from the path that leads to achieving that success before it is too late. And finally the user is involved constant providing guidance and feedback on leading to that final goal. Here is another blog post that does well in formulating some of these points.

So success is when the development team, stakeholders and the eventual users worked together to develop a product that met the criteria they worked on together to develop.

Of course if it is on time and within budget it will be a really big success….