Regardless of the design philosophy that will be used for the actual coding, the planning stage is perhaps the most important, at least when it comes to having a successful deployment. Many project management courses highlight planning as one of the key stages for any project; while agile development can mitigate poor planning, it doesn't completely eliminate all the problems.

Developing project requirements and evaluating them for incorporation is generally a job for the project or program manager, or whoever will be responsible for seeing the project to completion. A key point is that a project has a definite time frame associated with it; while work may be ongoing, a project has a designated start date and a completion deadline. This helps define what elements a project is supposed to have completed for the deliverable; anything beyond the scope of the project will be moved into a separate project.

Generally speaking, the key steps in developing a project are as follows:

1. Locate stakeholders, subject-matter experts (SMEs), and any relevant documentation and resources.
2. Identify the key problem(s) to be addressed.
3. Determine the scope of the project. This includes all the key features that will be included, as determined by the stakeholders. The scope needs to be reasonable for the given time frame, or the timeline extended.
4. Once the overarching scope has been approved, detailed requirements are developed and validated.

5. When the requirements are accepted, all stakeholders need to prioritize them, recognizing that low-priority ones may be pushed to the next version.
6. At this point, everything agreed upon should be formally documented to provide a roadmap for the project manager. This roadmap is vetted by stakeholders for final approval.
7. If the roadmap is approved, the project is frozen. Any additions or changes should be marked for inclusion in the next project, rather than modifying the current one. If the change is urgent and necessary, established change management processes should be used to document the change.
8. At this stage, the SMEs provide input regarding different options, solutions, risk factors, and costs. This input is incorporated into the development process.
9. The developers start work and provide regular updates to the project manager. This work continues until the project is finished, or at least this stage of a multi-phase project.
10. Any changes required are reviewed and assessed for relevance to the project's scope. If within the scope, the changes are documented via the change management process and incorporated into the project. If out of scope, the changes should be pushed to the next project.

There is much more to project management, as several certifications are available for the field, but this list should provide a general idea of the process.

The key takeaway from this section is that identifying and listing the requirements for a software project is important, as they guide the project from start to finish. Without clear requirements, the project can flounder.

An example from my personal experience should help clarify this. When placed in charge of a project at a new organization, it was discovered that the project had been in progress for 10 years and more than $1 million had already been spent. The project was to make a custom content management system (CMS) for the organization; the original designer wanted to use Python, so a third-party company was contracted to provide support to the in-house developers.

The problem was that the project was dictated by upper management and did not include the opinions or needs of the true users of the software. In addition, the requirements continually changed as leadership changed or new ideas were introduced. This was exacerbated by the fact that the users could rarely be bothered to test new versions of the software during development.

Thus, the developers were constantly trying to code for a moving target, and the contracted company didn't mind, as they were paid regardless. As a matter of fact, the company was able to use the knowledge from working on this project to create a brand-new version of their own CMS software.

Ultimately, I convinced management to abandon the project and find a commercial off-the-shelf product that met most of the needs of the users. That way, users could at least start working with something useful and request updates from the manufacturer as needed, rather than wait for vaporware that was never ready.