The title was a purposeful play on the acronym “IT” (information technology) because there is often no one person who takes responsibility for failed IT projects. In addition, it is not as if there are not project failures everywhere.
Notwithstanding one of my least favorite (but often quoted) research studies, the Chaos Report cites that about one-third of projects are successful when it comes to IT. What gets in the way of project success? Lots of circumstances and lots of people!
When a software intensive project fails, there is no lack of finger-pointing and blame sharing – yet seldom do teams stand up and confess that the failure (over budget and behind schedule and failing to meet user needs) was due to a combination of over and under factors, along with fears:
- overzealous and premature announcements (giving a date and budget before the project is defined);
- over optimistic estimates of how quickly the software could be built;
- under estimation of the subject complexity;
- assumptions that the requirements were as solid as the customer professed;
- under estimation of the overall scope;
- under estimation of how much testing will be needed;
- under estimation of how much time it takes to do a good job;
- under estimation of the learning curve;
- under estimation of the complexity of the solution;
- under estimation of the impact of interruptions and delays;
- over anticipation of user participation;
- over optimism about the availability of needed resources;
- over optimism about hardware and software working together;
- over optimism about how many things one can do at once;
- risk ignorance (“let’s not talk about risk on this project, it could kill it”);
- over optimism of teamwork (double the team size doesn’t half the duration);
- fear of speaking up;
- fear of canceling a project (even if it is the right thing to do);
- fear of pointing out errors;
- fear of being seen as making mistakes;
- fear of not being a “team player”;
- fear of not knowing (what you think you should);
- fear of not delivering fast enough;
- fear of being labeled unproductive;
- fear of being caught for being over or under optimistic.
Therefore, I ask you, on a software intensive IT project, whose job is it to point out when there are requirements errors, or something is taking longer than it should, or it is costing more than anticipated. In traditional waterfall development because there’s so much work put into the planning and documenting of requirements, pointing out errors are either no one’s job or the team’s (collective) job which really relates to no one’s job.
Often it is easier (and results in less conflict) to not say anything when the scope or schedule or budge go awry on a software project. Yet it is this very behavior that results in so much rework and so many failed projects.
Agile and Kanban projects are different
Several of the advantages to using Kanban and Lean and Agile approaches to software and systems development is that the methods address the very items outlined above. Building better software iteratively becomes every developer’s job rather than no one’s:
- Fear of pointing out errors is removed because the time that goes into a scrum is days and weeks not months (so participants don’t get defensive about change);
- Over and under optimism remains but is concentrated on smaller and less costly components of work (i.e. days instead of months or years);
- Risk is not avoided or ignored because we are no longer dealing with elongated and protracted development cycles (spanning seasons);
- Assumptions come out with better and more frequent discussions;
- Over optimism about how many things one can do at once is removed because Kanban limits the amount of work-in-progress;
- Under estimation of the impact of interruptions and delays is minimized because such factors are addressed in Kanban;
- Over anticipation of user participation is managed through direct user involvement.
What do you think? Join us at the Lean Software and Systems Consortium conference LSSC11 from May 3-6, 2011 as participants and speakers address the best ways of advancing software and systems methods including Lean, Kanban, Agile and other exciting new ways to deliver high quality software more efficiently and effectively.
These newer approaches make it easier for everyone in IT to make it their job to build better software.
Wishing you a productive week!
Carol
@caroldekkers (twitter)
It is everyone’s job to make sure that proper information goes to the right people and is not ignored:
* Developer should speak up.
* Developer should be heard.
* Hard facts must be tolerated by management and sales.
* Hard facts must be communicated to customer, so that delays and issues can be taken into account as early as possible.
It is everyone’s job to make sure that proper information goes to the right people and is not ignored:
* Developer should speak up.
* Developer should be heard.
* Hard facts must be tolerated by management and sales.
* Hard facts must be communicated to customer, so that delays and issues can be taken into account as early as possible.