Keith Watanabe * NET 2.0

You're group is working 12 hours a day for several months straight, even coming in on weekends.  People are tense in the office and finger pointing is going on.  Tempers flare at every meeting.  You hold more meetings in an attempt to put more management onto a problem.  People's health have degraded to the point where absences are occurring regularly. The system hasn't really made enough progress to where it's satisfactory.  Rumors fly about things that no one can truly substantiate.

What's wrong?

There was an article a while back on the failure of IT projects.  I'm in one right now where you're seeing these symptoms.  And it's not pretty.

This is not the first time I've been in this situation either.  Actually, I've worked at quite a few places where this situation occurred. 

I've also been in companies where I've worked with highly successful projects that were delivered on time.  So by that logic, I know the fault wasn't entirely on me.

Yet, do you ever get the feeling when you know failure is imminent, no matter what you do and how hard you try?  What I described above is that clear sign of failure.  But I think the root cause is far deeper.

- Reactionary management.  When management begins making arbitrary decisions, it implies that they are only looking at deadlines and deliverables, not the overall picture.  I find reactionary management going on in smaller companies where processes are not well defined as well as in start ups or companies with little experience in handling IT projects.
- Unfocused agenda.  You need to understand why a project exist in the first place.  Do a CBA to really get a better picture of what goes on.  More importantly, understand the goals of the project.  In my situation, one of the key drivers was building an in house team to deliver higher quality code while bringing knowledge in house.  Part of that situation was utilizing an existing pair of systems which were problematic in the dual maintenance and consolidating them for the distributors' sakes.  At this stage, all the focus has gone towards the code deliverables because a vendor took over.  Well, again going back to the original idea, we were supposed to move away from using vendors and increase the in house knowledge of our people.  Management had forgotten this, or rather never cared as hidden agendas started popping up.  Still though, one key premise was removed from the project's goal, which is why the team lacks focus and is frustrated.
- Missed milestones.  This is obvious, but people rarely want to blame lack of planning as a root cause.  You have to clearly reason and allow for margin of error when it comes to choosing deadlines.  You won't truly understand a hard deadline until people really get into a project.  Otherwise, you need a truly experienced planner to detail the breakdown of the deadlines.
- Never overpromise.  Promises are made to be broken.  This is just a rule of thumb.  Live by the software rule: underpromise overdeliver.  Don't promise something until people truly understand the extent of the problem.
- Constant scope creep.  Scope might not necessarily come in the form of just requirements.  It could hidden requirements or implied requirements as well.  Hidden or implied requirements are those that come up at a later time that people realize are necessary, but only at the time when being dealt with.  Be forgiving on this point at people cannot always foresee everything little detail.
- Changes in requirements during build phase.  This only hurts if you're working with an inflexible model.  But once requirements are nailed down, they must be signed off, never to return under all reasonable circumstances.
- The waterfall SDLC.  It sucks.  Plain and simple.  They should delete this from software engineering classes and put it as a footnote in the failure of human history.
- Adding more resources.  Read: put more people on the project as the project goes on.  Especially engineers.  Wrong reasoning.  The starting team needs to end the project together, unless people have personal reasons for taking off.
- Allow for about 10-15% margin of error.  Japan needs to start understanding this aspect of software engineering.  Then again Japan needs to start being more flexible and understanding in general.
- Scattered requirements where people are asking the same question more than once.  That means that the format and ways of locating the requirements have been poorly executed.  Don't overcomplicate requirements and don't go into every little detail for requirements.  Most of all, make sure those requirements are easily available for anyone to reference.  Definitely don't have them on some shared drive displaced in multiple areas.

I can go on about this (and I might add to it later).  But I have to return to my failing IT project.  Happiness.