Our Client wants to build a new software system, due to changing regulations, new business initiatives, some merger/acquisition of external systems, or startup technology needs:

"How do we identify and make the correct decisions about project scoping and execution to ensure our time, cost and quality objectives and constraints."

"How do requirements need to be captured? And to what level? How do we avoid wasting valuable time trying to collect requirements? When is it enough?"

"Who will be able to review the requirements, and catch problems before expensive technical work begins: syntax/semantic errors, conceptual mistakes, ambiguities, conflicts and/or gaps?"

"What's the risk of further wasted time and money and opportunity losses, when these problems are not found until we're in the middle of development, testing or in production?"

"What technology platforms are practical, which should be chosen? Within a given platform, which technology stack combination should be targeted? What architectural risks need to be addressed?"

"How can we receive the project deliverables in the fastest time possible? Before the underlying business needs change or become obsolete?

"How can we build the solution quickly to harness opportunities and shield risks and liabilities?"

"How can we ensure the vendor does not veer from the expected time frames, cost estimates or quality targets?"

"How can we and the vendor perform the correct level of testing? How much and what types of testing are needed? At what point do we face diminishing returns?"

"What provisions and tactics should we consider to ensure smooth product acceptance, staging/beta and production deployments?"

"What post-deployment risks and concerns should we analyze and resolve?"

Existing software code does not accurately reflect the intent and decisions of the business processes it was designed to support. Often, the existing source code has evolved over time and is missing original specs or has diverged from past specs. So usually a lot of underlying business knowledge and use cases must be reverse-engineered and documented first.

Consequently, the surrounding business processes have evolved into inefficient compromise states, balancing between changing business needs and existing software limitations. Such processes must be re-designed and paired with new software feature/functions. This creates new software requirements, in addition to the originally proposed feature/functions.

But the software system often has complex inter-module and intra-code dependencies that increase the risk of side effects from thoughtless code edits. Even when fixing defects, it is common for programmers to introduce new unintentional defects that increase risk to quality, time and cost.

It gets further difficult when the existing system is missing some or all testing documentation or test automation scripts that can be used for regression testing and verifying functionality. How can we measure whether enhancements have created diverging functionality?

And of course, Clients still face all other challenges of software development, related to technology, resources, project management/execution, quality assurance, etc. Many companies are forced to rewrite software systems rather than risk the nightmares of trying to upgrade old software systems.

Another layer of comlexity occurs when the project was written in legacy languages: the current staff is not sufficiently experienced in the legacy tech stacks, cannot understand current nuanced software behavior and cannot be expected to make correct migration deciions.