After your free initial 30 minute consultation with Tom, we begin a Feasibility Analysis stage and start defining the project requirements with the regular weekly retainer lasting on average 12 weeks and then dropping down to a monthly retainer for maintenance long term. Due to the iterative nature of the central project execution stage, the project plan can change accordingly.
While on retainer you can engage and spend time without the fear of receiving a large invoice. Increases in retainer are only with express consent, see direct debit terms.
This excellent chart is sourced from:
Excerpt from the article:
Feasibility Analysis compares major alternative solution approaches to determine whether each approach could achieve desired results and which approach is most economically effective. While Return on Investment (ROI) should be calculated at various key points throughout a project to make sure the project still is worth doing, most projects calculate ROI only once if at all, at the very beginning during Feasibility Analysis.
Regardless whether it’s conducted explicitly, every project includes a Feasibility Analysis phase, because that’s when the project management life cycle Initiation, Planning, and Organization phases occur. This phase defines the project and sets its budget and schedule. Impossible budgets and schedules usually result and destine a project to fail when Feasibility Analysis is done implicitly, unconsciously, and inadequately.
A main project-dooming cause of inadequate feasibility analysis stems from failing first to discover the top-level REAL business requirements that provide value when met. Each alternative approach’s feasibility should be evaluated with respect to its ability and cost to meet those REAL business requirements. During the later Systems (or Requirements) Analysis phase, the top-level business requirements are driven down to detail, which then becomes the basis for high- and low-levels of System Design.
However, most projects fail to adequately identify the business requirements. Instead, they start with the high-level design of the product, system, or software they expect to create and thus have no meaningful basis for assuring it will provide value, let alone reliably measuring its financial ROI. Such projects invariably suffer extensive creep in order to fix inevitable functional shortcomings, which in turn lead to budget and schedule overruns.
In addition, as commonly carried out, projects following various iterative development methodologies generally suffer from a second Feasibility Analysis phase form of inadequacy. When used effectively, such methodologies perform overall product planning during Feasibility Analysis to identify and sequence the requirements, design, and development iterations needed.
In contrast, most iterative development simply plunges into coding pieces of the product without suitable prior planning to determine what pieces are needed, how they will fit together, and what the most appropriate sequence is for creating and integrating them. By not taking advantage of the Feasibility Analysis phase, time-consuming and expensive excessive iterations often are needed to correct architectural shortcoming.
Life cycles are defined to help one succeed, not to create a mass of bureaucratic busywork. Using the life cycle to guide one’s work, when applied in an informed and flexible manner, indeed can increase chances of success.
Project Requirements
- Why are we doing this project?
- What is its value to us?
- What is it supposed to do?
- How do we know it’s correctly doing what it’s supposed to do?
- How sure can we be that it will keep working correctly?
Business Requirements
User Requirements
Functional Requirements
Business Rules
Non-Functional Requirements
Inspired by the process used at Segue
Software Requirements Take Different Forms for Different Aspects of Development