en-us http://www.keithwatanabe.net/index.php Keith Watanabe's Website http://www.keithwatanabe.net/blogs/2007/7/23/e52ec98e860335245c30658dfcf9684e.html
As I grow more experienced in the realm of IT and software, I'm seeing this trend all too often. What goes on during a failure? What are the symptoms?

There was a fantastic article on the CIO.com on why this occurs. I'm not going to reiterate the article, nor link it. However, I want to offer my insight especially as my own project is nearing disasterous proportions:

- Inflexible deadline. My current project had preset it's deadline at an early stage, way before the build began. The developers didn't get one shot in to really provide their input in how long their effort would take. Instead, we were given a timespan and forced to work within those boundaries. The consequences for such inept planning are low morale, high absence rate, long working hours, hostility amongst members, limited ability to plan, and a natural discomfort to provide truthful answers when ever counterproposal would be immediately rejected by management.
- Not well defined resources. This came in the form of defining the types of people necessary to execute the project correctly, at least within the boundaries of development. When the immediate resources initially defined to be used were unavailable (two other guys, one didn't even bother joining the company), we turned towards a contingency plan, which was a vender. Turns out that the vender saw a great opportunity to leech off management and inject themselves and attempt to swipe the project. However, that wouldn't have been such a problem if we had clearly defined the level of developers needed to work in this project. Not just level, but the maturity as well. For instance, knowing how to use Hibernate, Spring as well as being detailed oriented and independent in thinking. We barely tested to see their knowledge in programming Java, so we got low end developers that became a huge detriment to the project.
- Lack of confidence between business and IT. I think this is where the Waterfall software lifecycle model is an absolute failure. I see too many failures in projects because there is little to no feedback between business and IT. More importantly, scope and adjustments to the project cannot be made in time because of the fact that you'd have to return all the way back to a previous process/phase. Simple logic would dictate that sign off indicates no more scope creep happens. However, as most of us realize, that's never the case.
- Introducing resources (people) late in the project. This goes to the whole notion of diminishing returns in terms of adding more resources to a project. You truly want to avoid this situation at all cost, especially if you are under a severe deadline. Unless someone is an absolute genius, you cannot rely on a person coming up to speed. There seems to be a poor habit demonstrated by management to add resources, even in increasing the budget of a project. That simply means more headaches, especially for the key resources that do understand the project quite well. The education and ramp up time for this when introduced late in the game means certain people (the key resources) will be spending more time educating these people, rather than focusing on their own tasks. I found this issue to be the biggest killer in my current project.
- Unwillingness to reduce scope. If a project starts moving in the red, you probably want to limit the scope. If you don't, you run the risk of hitting an unavoidable brick wall, which is the inevitable project's failure. Cut out things. Ask if something is necessary.
- If scope is added, force the business side to agree upon increased time.
- Budget at least an additional half amount of time originally slotted for the project. This time compensates for sickness, jury duty, vacation, etc. People are not consistent, so don't expect your project to be like that.
- Provide constant incentives for your team when things are looking bleak. On the first few signs of danger, make sure that the team is appreciated and that small things are given. For instance, if teams cannot take vacations, compensate by allowing them to come in late (since most likely they'll be working long hours). Or buy them lunch, snacks, coffee, etc. Anything that's a morale booster is something that the project management should do to ensure that people feel that they are cared for. Don't go too cheap either. You don't have to buy them a hooker or a new car, but tokens of appreciation on occasion demonstrates what the project and team members mean.
- Make sure the lead people are capable. I'm encountering situations where there's mutiny amongst the team members. Team leaders ought to be able to answer roughly 85-90% of the questions. Also, they ought to set good examples so others are willing to follow. Trust between your team members is critical. Remember: it's a team, not just one's own glory.
- Make certain that people are not single points of failure. I've seen everyone place a lot of emphasis on systems as being points of failure. But in reality the people maintaining the systems are just as critical if not more so because of their knowledge on how these systems can fail. Don't force nor allow one person to be that failure in a project. Make sure there is enough redundancies in knowledge in case something happens to that person (not to mention letting that person take an occasional break!)
- Make sure your team members get along. I'll admit that I don't like 80% of the people I'm currently working with. I feel that some are cold, aloof, and uncooperative. Perhaps, they feel the same about me. However, the problem is that we took them without really attempting to get a feeling of chemistry between people. That's a huge amateur mistake on our part, but in my case, I didn't completely make the decision.
- Minimize meetings. Developers need to develop, not talk. Utilize technologies that help improve communication with minimal disruption. Wikis, chat programs, and automated tools that send messages for things like CVS/SVN commits are mandatory. Meetings are for managers. The rest of us need to do real work.
- DO NOT HAVE A MILLION DOCUMENTS!!!!! Centralize your documents into one spot. Use a wiki or something searchable. My company is retarded and utilizes a horribly disorganized shared drive system that have an unfathomable number of folders and subfolders, with little meaning and are impossible to navigate. Worse yet, the documents are split up in these folders. Some things pertaining to requirements occasionally are in folders that are meant for scope or design. Then they use Word and Excel to manage this! There's many wiki tools out there that help index your documents and make them very navigatable with versioning. Word and Excel do not provide good indexing capability, so avoid them like the plague.
- Allow the build phase to come immediately into the project. Let the groundwork be set by the developers so that they can get an immediate sense of the project scope. I've found myself refactoring so much or not completely understanding the requirements or existing system that my times get skewed when doing estimates. I'm certain most developers feel the same way. But again this goes back to allowing the developers to dictate a huge part of the schedule since they know themselves quite well.]]> Mon, 23 Jul 2007 09:12:45 -0600 http://www.keithwatanabe.net/blogs/2007/7/23/e52ec98e860335245c30658dfcf9684e.html http://www.keithwatanabe.net/blogs/2008/9/2/18bf6e4e100e3f977a52d5076cbf078c.html
There's a sweet group of tools for creating DVDs that you can watch in your player. Among them are DVDAuthor and tovid. DVDAuthor is the real tool. Very simple command line scripts that will practically do everything including burning your DVD. Tovid, on the other hand, is a group of command line tools and GUI tools to customize your DVD creation.

What I really like about DVDAuthor is that you just have to type:

makedvd -burn /path/to/your/VOBs

Extremely simple.

By comparison, the tools for Windows usually require a license or inject some sort of watermark for shareware versions. This is just another motivation to make a switch to Linux. When Linux works, it works well.]]> Tue, 02 Sep 2008 08:58:15 -0600 http://www.keithwatanabe.net/blogs/2008/9/2/18bf6e4e100e3f977a52d5076cbf078c.html http://www.keithwatanabe.net/blogs/2008/11/9/b43dbfb2eb4dbe6f6ca835dd52b6e034.html
In other words, just go work at startups.

Best practice would be for people to start welcoming sexual harassment with open arms. Maybe if people didn't have a stick up their ass about the dating game and just let people be our natural animalistic selves then crap like this wouldn't exist.]]> Sun, 09 Nov 2008 01:55:26 -0700 http://www.keithwatanabe.net/blogs/2008/11/9/b43dbfb2eb4dbe6f6ca835dd52b6e034.html