Top ten critical success factors in software project
Having worked in the software industry for almost 20 years now, I don’t count myself to be the smartest or most skilled in the trade, but I always had a lot of opportunities to work among the brightest and talented people. And unfortunately, I had also worked with idiots and jerks.
I had the opportunities to work on small and large projects, there are many successful projects as well as many failed ones, ranging from a two-person projects to ones with hundreds of millions of dollars in budget.
On a personal level, I had learned a lot from the failed projects. I don’t believe I have completely grasped the full breadth of software project yet, but I believe I have learned from the mistakes, would always try to avoid the same traps in the following projects, and would always try to bring in improvements to the methodology.
From the experiences, I have collected my own list of critical success factors.
- Cooperative team: A cooperative team, with dedicated team members, is always the first success factor for me. A project team is like a sport team. If you have non-cooperative members on the court, you will never win the game. I’d like to have rock stars in my team as much as the next guy, but personally, I’d rather have a team member with mediocre skills, but very cooperative and dedicated, than a rock star who is being an asshole and pisses off everyone in the team, and who would go on to do everything his own way, without taking into consideration the team’s objectives and goals. In any large project, no single person can do everything. That’s why you need a team. We see all-star team fail miserably all the time. There’s a reason to it.
- Clear requirements and specifications: Researches after researches have shown that this is one of the most critical success factors, if not the most critical. It’s common to see programmers start writing codes without even understanding the requirements, and without working out detailed specifications. The end result, usually, is patches on top of patches on top of patches, and before you know it, you code yourself into the corner and the project gets out of control. And if you have a team of cocky, self-proclaimed rock stars who don’t give a shit about each other, and who are more eager to show off their coding prowess than anything else, you will never have clear and detailed specifications.
- Clear objectives and goals: If you don’t have clear requirements and specifications, it is impossible to have clear objectives and goals. That is common sense, and it just flows straight from the previous item.
- Realistic schedule: If you don’t even know what you are trying to achieve (objectives and goals), and you don’t even know how to do it (detailed design), and you haven’t even gone through a thorough thought process (detailed specifications), who tells you that you are even qualified to provide an estimated schedule? From my experiences, never trust programmers on their estimated schedule, especially the self-proclaimed geniuses. Their ego is always bigger than their grey matter.
- Effective communication: If you have a team who is more eager to show off their big dick than having a successful project, and if you have already skipped all the above, you can be sure that communication is broken, off the bat. No tool, no workflow, will save you. Effective communication is built on the basis that you have a team who wants to communicate, and that you have something to communicate with, which is your requirements and specifications, your objectives and goals, your schedule and status. Have you sat in a meeting where there’s no basis for discussion, and no one knows what is going on? Does it sound familiar? It does, because it’s quite common.
- Support from top management: If you have a non-cooperative team and a broken process, and the top management is conniving it, no matter how much effort you put in to align your work with the objectives and goals, you are doomed from the start. Top management should always set example, should never tolerate non-cooperative behavior, cockiness and assholes. When it’s time to make tough decision, just do it. If you don’t make tough decision when it’s necessary, you are conniving bad behavior. Bad behavior pollutes your work environment and your team. One bad apple is enough to spoil the whole basket, and when you have more than one, what do you think it’s going to happen? At the end, everyone, including your good team members, will behave like assholes, because it’s tolerated and encouraged. Before you know it, you are having a team of assholes, as those who don’t want to be assholes have chosen to leave.
- Effective project management: For me, project management is a process to create an environment so that every team member can do his/her work effectively, and a workflow to align everyone’s objectives to the project’s objectives. When you have all the above, project management is going to be effective.
- User/Client involvement: Don’t try to be smart, and don’t ever think your users are stupid. No single solution will fit all needs. Always try to provide options to your users, especially your advanced users, as they are your market thought leader. That’s why you always need to involve your users, and study what they want and how they use it. Yes, Henry Ford once said that if he had asked his customers what they wanted, they would probably ask for faster horse carriage. There’s a lot of cockiness in that statement. If Henry Ford hadn’t figured out there was a market for automobiles, would he still be in this business? How did he know there was a market? Henry Ford did not invent automobiles, he improved the manufacturing process. He had seen how customers wanted automobiles, that is client involvement, although indirectly.
- Realistic budget: Plan your budget accordingly. Plan accordingly is only possible when you know what you want to achieve, how you want to achieve it, and when you want to achieve it. Planning a budget without the above is like pulling it out of your ass. In case where you have pre-determined budget, if you have clear requirements and detailed specifications, you can plan it backward by scheduling the works into multiple phases. Forward or backward, it always depends on how much preparation works you have done.
- Familiarity with technology: People will tell you that since we are using new technology in the project, which is common in software projects, and since we are not familiar with the new technology yet, there’s no way to write design document and detailed specifications. That’s bullshit to cover up their incapabilities and idiocy. Go ask the aerospace engineers, aeronautic engineers, mechanical engineers, civil engineers and architects, etc, they all have to overcome many many more technological obstacles than programmers do, yet no one is complaining that detailed specifications are a waste of time. Who are we to say so? That’s why design document and detailed specifications are very important, as it forces us to do research, get familiar with new technologies, new ideas, new algorithms, know what to do and how to do it.
I just wish that software could become an engineering field, not some kind of black art by assholes who claim to know better than everyone else. And we should never connive the assholes’ behavior, it’s bad for everyone.