When it comes to development in a team environment there are two methods that remain strong in the industry, Agile and Waterfall. These two pathways are very different financially and in approach. To go further into detail each approach should be explained how it correlates with time management, finances, and purpose.
One thing to note is that there are very rare instances where either method is used in its purest form. Likely there will be a merging of the two or evolved adaptations to meet needs of a particular company. Another important note is that while these two methods are different from each other, they can both be used to achieve the same goal.
Most development shops use some form of the Agile method which is typically a less formal way of achieving goals and allows for flexibility in a project. The client will have opportunities to change the scope of the project to a degree because of the amount of meetings typically involved. There are a few key players Product owner, http://www.scrumalliance.org/why-scrum/scrum-for-the-agile-organization Scrum Master (get certified then have people call you Master!), and Team members. The Product owner is responsible for communicating the idea for the project to the development team. This could be a business liaison from Company X that the development team would work with to ensure the product meets standards. The Scrum master is responsible for making sure the goals are being met in reasonable time frames and takes care of eliminating any obstacles along the way. The Scrum master might be a more experienced developer with strength in creatively solving problems to achieve the end goal or short goals (sprints). Team members are the people responsible for developing the products and hitting the goals or tasks given to them. These team members could be front-end developers, back-end developers, QA experts, solution architects, or any other skill set necessary for that particular product.
At one time the more dominant method considered to be the standard was the Waterfall method. This typically is a better solution for smaller products. The main difference here is in the amount of planning and meetings. The goal is to get as much information set in stone as possible so that there is little to no change in scope of the project. This method is good for planning the financial aspect of a project because all expectations are on the table from the beginning. This also makes it much less flexible, in other words – “Once you leave the station the train is not stopping until it reaches its destination.” Developers generally like this type of approach because it is unlikely to have any major changes in design or functionality. The planning stage may last a long time, but it can speed up development quite a bit based on full understanding of expectations.
What a lot of companies do these days is merge Agile and Waterfall. This can be beneficial for both Client and Company to maximize cost effectiveness and productivity. Setting expectations upfront with some wiggle room and holding meetings to discuss both short term and long term goals can get the project rolling before all planning is completed. For clients who want to add features as they think of them this is a great method to use if they have proper funding.