Software development under Waterfall Project Management

Intro

I am an experienced Business System Analyst. I've worked for large to medium sized organizations supporting business users up and down both US coasts. I've supported from large advertising agencies to small motorcycle dealers and CPA firms.

I've designed, documented, tested, trained and maintained business systems from Accounting, Finance, Document Management, Customer Management, Service claim managements to Student Scheduling. In terms of platforms, I've worked with back-end mainframes, client-server and web based systems.

My passion is to help businesses and individuals streamline their processes, automate when/where possible, and squeeze every ounce of efficiency where possible. In addition I train users on the new system and show them the "how-tos" of the new system.

The following is a high level outline of my understanding and experience as a BA under waterfall project management.

Software Life Cycle

Requirements Definition/Scope  
The software development process starts with identifying the objectives behind a system or enhancement. One needs to understand whether the new system will address a new opportunity or if it's to replace an existing system. In the latter case, you will need to understand the old system before you can document the to-be system. For this, you will need to review existing documentation or meet with business subject matter experts to review the current functionality/procedures.

There are countless problems in any business, most but not all can be helped with technology. Notice that I did not say solved. I believe technology can get us close, but never quite reach 100%. Even without a silver bullet, however, businesses need solutions pronto. Technology can get us there 80%, and the remainder 20% is a manual task or a future build.

Once the problem/opportunity has a solution identified, scoped and documented, all stakeholders need to review the documentation to confirm that all needs/requirements have been captured.

The biggest challenge: This stage is critical and can take some time as stakeholders can go back and forth agreeing what is needed. Politics often come into play at this stage. It is key to maintain management appraised of this progress. Often times, it is necessary to involve management into the approval process.

The reason this stage is critical is because not capturing the correct requirements can quickly drive up costs in later stages to go back and retrofit the system to address missed needs. Also, if the stakeholders cannot agree on the requirements, the project can and most likely will be shelved or even cancelled altogether. Remember, the business does not have a single problem to solve. Solutions are constantly competing for resources and if one project is taking longer than originally planned, a new, more pressing or with higher return on investment project will take its place.

Once this document is approved, the established requirements become the baseline. Any new requirement should be managed separately from the original ones and developed post system implementation.

Functional Requirements
Once you understand the what and why and have stakeholder approvals, then the BA can proceed to the how of a system. This is the stage when IT is brought about platforms, systems, Databases, Data Mappings, EDI connections to internal and external systems, servers for development, staging and production.

Since IT manages the technical platforms, they will decide the best tools to develop and deliver the new system. For example, a Big Blue shop (IBM) would probably stay away from cloud services or if a client is heavily invested in Microsoft, they would probably not consider installing and running Linux servers.

IT, then, will review the requirements documents, their existing platform, consider future updates/upgrades and will come back with an estimate of resources needed (time/cost/manpower/technology) to complete the system or solution.

Development and Unit Testing
Management will need to review and approve IT's proposal and then and only then can design begin to be followed by development and unit testing also known as Alpha testing. While developers code, network engineers install and test servers, Database Administrators review and plan data tables, elements, SQL extracts for reporting, etc.

Once Unit Test is complete, IT will need to prepare a Staging environment and load it with a copy of production data for UAT.

Planning for UAT in Staging
Because the BA has been involved from the start, he/she is in great position to plan and manage User Acceptance Testing, UAT. The BA will review the success criteria for each functionality and maps it into the UAT plan. UAT is done by Subject Matter Experts, SMEs, or the business users who provided and confirmed the requirements. In my experience SMEs are the only ones who truly understand the business and can spot issues with the data or expected functionality.

Sign-off and Implementation
At the end of UAT, management, based on SMEs recommendations, will sign-off and the system can then be implemented into a Production environment.

Project Sunset
While not everyone engages in this activity, I think they do so to the detriment of both individuals and the organization. This is something that should be done. This is where the team reviews what went right and what went wrong. This is very important: You want to avoid that which went wrong and repeat that which went right.