Disclaimer: The experience shared below is purely derived out of a project that was executed following the waterfall model. While most of it applies to other types of development styles too, not all of it may work. Hence do take each tip with a pinch of salt!
- Knowing your team is as important as knowing your customer.
Why do I say this? 9 out of 10 times, development projects are executed against tight deadlines and hence time (which directly impacts the cost of execution of a project, more so if it is a fixed price project; you cannot afford to bleed too long, if you slip too much) becomes a differentiating factor in deciding the fate of a project. When you are on a development project, it is extremely important to know your team very well. It is more like playing a 20:20 match. You have got to make the most out of what you have; both in terms of time as well as resources. This can only be done if you know the strengths and weaknesses of each of your team members really well. Once you know your team well, you can etch out an effective game plan to tackle the project by utilizing every team member to the fullest.
- No matter how great plan A might look, always have a plan B.
They say, “Failing to plan is planning to fail”. Planning is undoubtedly the most important thing for the success of any project. But since software development is an iterative process, not everything can be planned in advance. It really helps to keep re-visiting the planning aspect of the project regularly and make suitable modifications to it from time to time. Why is plan B so important? Well, nothing (even no one) is infallible. Things can really go out of schedule due to various reasons and might demand periodic interventions to repair the slippage in schedules. In other words, watch out for incremental slippages and act soon to make up for them. Schedule-keeping is very important if you are to taste success even remotely in a development project.
- Avoid re-work, design well.
The design phase is probably the most important phase of any project. It requires utmost attention and it is absolutely fine to spend a little more time here than to jumpstart development. Why do I say this? A lot of times, it so happens that under the pressure of meeting the deadlines of a project, people are forced to jumpstart development while the design is still underway. To me, it is as good as asking the soldiers on the frontier to start the battle while the general is still preparing his final draft of the war strategy! It is very important to understand that every single day invested in to the design phase can save at least two to three days (at times even more) of development effort. Imagine those ‘nth minute’ changes to your database tables or a major design flaw discovered during the later phase of a project. It can cost you fortunes. So spend enough time here. You will never regret it!
- Think before you code.
This is one solid piece of advice our tech lead gave us when we were just heading towards the beginning of the coding phase. He put it in a way that ensured that each one of us not only understood it but also implemented it. He shot a mail to all of us which had a quote from Abraham Lincoln, “If I had eight hours to chop a tree, I would rather spend six hours sharpening my axe.” He was spot on! I strongly believe that if one spends considerable time into thinking exactly what needs to be coded, the actual time required to code is very minimal.
- Housekeeping isn’t necessarily a task for the maintenance team.
Housekeeping job, and that in a development project! Joking?! Well, I am not. When I say housekeeping, I mean tasks like ensuring all the team members adhere to the process set up in a project like coding standards, usage of project specific templates, documentation, etc. I also add one more task to the housekeeping category, which I feel is often overlooked. How many teams have a plan in place to educate new joiners of a project and make them understand the processes and standards of the project? In other words, how many projects have the bandwidth to accommodate the luxury to educate new joiners? You may ask, ‘What’s the big deal?’ Well, it really is. It often happens that due to time crunch, people who join in the middle of a project might not have enough time on their hands to get acquainted with the processes of a project. When such a thing happens, slowly but steadily deviations in the project start to creep in. It might take various forms, like non-conformation to coding standards, gaps in requirement understanding, etc. All the effort put in by the project team from the beginning to adhere to a specific process might go for a toss. Is it all worth it? Think about it.
- Innovation = Being wiser than what you were yesterday.
Many a time we hear about innovation and how it must be an integral part of a project and so on and so forth. How many times does it make sense to you? Well, to me, innovation is nothing more than being wiser than what I was yesterday! At the end of the day, innovation is doing things in a way that is better than the way it was done yesterday. If you are vigilant enough, you will find umpteen opportunities of innovation in your day-to-day life ranging from how you schedule your time to how you respond to a problematic situation. Think about it. Innovation need not always be path-breaking. It can be simple things done in a different way.