Google search returns over 95k results for “poor requirements”.
Software projects are continually 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 abroader scope. And others do not cover required depth. Project teams do not often share the outcome of Analysis with the client upfront. So, the client does 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 a different objective. Therefore, the techniques, tools and deliverable used in each step are different. Project team must understand these differences.
- Start with end in mind: Project team must understand purpose, plan and deliverables of the 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.
E.A scope is an entire enterprise (refer following diagram – Singh’s BRM):
or, another description – Porter’s Value chain model:
Find out more about E.A from the following slideshow:
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, the project team may identify multiple initiatives. Client prioritise initiatives which is known 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 to 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 a detailed solution design based on business requirements.
Detailed Design aims to describe how software will offer a solution to the identified needs. It helps stakeholders to develop a shared understanding of the proposed solution. DD helps to build consensus on the solution before an investment is made on the development.
Deliverables: Functional Design Document (FDD), Prototype, Proof of concept, wireframe
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.