Google search returns over 95k results for “poor requirements”.
Software projects are constantly failing due to poor requirements.
Here are few stats: (source: http://custom-business-software.com/cost-poor-requirements/)
Often Analysis is unstructured. The outcomes of analysis are vague. Few deliverables do not cover wider scope. And others do not cover required depth. Project teams does not often share the outcome of analysis with the client upfront. So, client do not know what to expect out of analysis?
Therefore, analysis stage is full of surprises. Requirements are poorly documented. And project starts with the weak foundation.
So, what is the proposed solution to the above problem?
- There are three analysis stages: Project teams must understand, which stage they are in. More details covered in the following section.
- Understand the purpose of each analysis stage: Each analysis stage has different purpose. Therefore, the techniques, tools and deliverables used in each stage are different. Project team must understand these differences.
- Start with end in mind: Project team must understand purpose, plan and deliverables of each analysis stage. Then, set expectation on the outcomes and deliverables with all stakeholders.
Let us dig into three analysis stages:
- Enterprise Analysis
- Project Analysis
- Detailed Design
1. Enterprise Analysis (E.A): It is the big picture analysis. The focus is on the overall enterprise. The aim of enterprise analysis is to define the high-level business problems, requirements and solution options.
Business strategy, goals, short/medium term plans, business constraints, existing business case(s) are inputs to E.A.
EA scope is entire enterprise (refer following diagram – Singh’s BRM):
or, another diagram – Porter’s Value chain model:
Find out more about EA from the following sideshow:
Deliverables: Business Problem statement, Portfolio/Program/Project Scope document, Program of Work document, Business Needs Analysis, Business High Level Requirements, Business case, RFP, RFQ, Portfolio/Program/Project road-map, Product backlog
2. Project Analysis (P.A): Out of EA, project team may identify multiple initiatives. Client prioritise initiatives. Each initiative is identified as a separate project. The scope of analysis is limited to the project scope. The product/outcome from this project servers as the foundation on which later projects.
The objective of project analysis is identify detailed requirements (over 61 different types) and solution approaches.
Deliverables: Business Requirements Document (BRD), Solution Analysis and Design document (SAD), User stories, Sprint plans, Business rules documentation.
3. Detailed Design (D.D): The focus of this analysis is to formulate and document detailed solution design based on business requirements.
The aim of Detailed Design is to describe how software will offer solution to the identified requirements. This helps stakeholders to develop common understanding on the proposed solution. DD helps to develop consensus on the solution, before investment is made to develop it.
Deliverables: Functional Design Document (FDD), Prototype, Proof of concept, wire frame
Scope and Detail of each analysis type is different:
To conclude, for successful analysis, it is vital to understand:
- Type of analysis you are undertaking
- What are the planned outcomes of analysis?
- What are deliverables?
- How deliverables look like?
- What is the level of detail and scope of analysis you will be undertaking?
I hope you find this information useful. Please share your experiences on this topic.