Story Point - Not an effort estimation

I always use to think that Story Point is an effort estimate technique till the time I actually encountered and applied in project.

It is important to understand that Story Points are relative complexity estimates and not effort estimation technique. It is always RELATIVE and not ABSOLUTE. Let me explain in crisp.

1. Breakdown user stories to unit of relative size (small, medium, large, extra large....)
• To compare feature relatively
• Substitute to time
2. Story points are not a measurement of duration but simple measurement of size/complexity
3. Start with any standard feature and then other features(user stories) are 1X, 2X, 3X etc smaller or larger than that relative feature in size

Project Estimates - Cost, Effort, Schedule, Timeline, Team Structure

How to estimate efforts for a project? This is a big question every time for many when they get new set of project requirement. Efforts estimation is not enough alone. We also need to do alignment and distribution of hours among the team and carve out the timeline and deliverable's for the project. I always use below simple format to  calculate project cost, efforts, timeline, deliverable, effort distribution for dual/single shore mode. Easy and simple format where you can put everything at one place and can be used as a dashboard for management view.

Duration	Milestones	Deliverable	Architect Onshore	UX Designer	SharePoint Onshore Dev	DB Offshore Dev	Offshore Test	Total Hours
Wk-1	Analysis		40	20				80
	-Requirements Analysis	Functional Spec
	-User research	Design wireframes
Wk-2	Planning		40	40	20	40	20	170
	-Information architecture	Process flow Diagram/Site map
	-Finalize architecture	Development Specs
Wk 3-7	Implementation Phase		80	40	80	400	200	880
	-UI design	UI Frames
	-Backend Design	Demo -I
	-Workflow Design	Demo - II
	-Test Cases/Test plan	Test Plan
Wk 8	User Acceptance				20	80	40	180
	-User Documentation	User Guide
	-UAT Support	Helpdesk Support
	-UAT Sign off
Wk 10	Product delivery				20	40	20	90
	-Deployment Instructions	Deployment Guide
	-Deployment Packaging	Deployment Build
	-Code Hand Off	Code Database
Hours Total			160	100	140	560	280	1400
Rate			$	$	$	$	$	$
Estimated Cost			$	$	$	$	$	$

Project Gate Review Process

I have always been asked by many people what is the best way to inculcate a good review process around a project to stenghthen the delivery process. This caused me to think and implement below Gate Review Process to my projects. Trust me, this process has resulted realy good outputs/results if followed religiously.

Problem Statement

            Most of the project delivery goes through the critical path at the time of final delivery, and one of the reasons is observed that during the whole SDLC we are not reviewing the completeness of deliverables. This results in not identifying the risks at the right time and issues/rework at later stages.

Proposal

Gate Process: In a SDLC process, the whole delivery is divided into several phases. Each of the phases has pre-defined entry and exit criteria. For every phase, there is list of stakeholders who needs to review the progress of the last phase and decide to move to the next phase.

Rules and Procedure:

1.    A Gate need to be approved before starting on next Gate

2.    Gate Owner is responsible for arranging the Gate review meeting. Along with meeting request, he should send the list of deliverables for review

3.    All the Gate reviewers must give their approvals/review comments either before (via email) or during the scheduled/planned meeting.

4.    Gate Approver will take the final decision to approve/reject the Gate or passing it with Concession(with list of action items along with their closure dates)

5.    A Gate can be approved with concessions (List of Pending Action Items with defined closure dates) but the next Gate can’t be approved, unless the concessions taken in previous Gate are addressed.

6.    Gate Owner will publish the Gate Report on Close of Gate Meeting.

7.    Every project plan should have these gates defined with planned dates and efforts.

8.    In-case the Onshore PM/Offshore PM/ Development Head needs any tailoring in above process, due to project requirements, the concession for the same needs to be taken in G0 or G1 phase.

Gate	Gate Name	Owner	List of Deliverables	Gate Reviewers Mandatory (in Green), Approver(in Red) and Stakeholder (Blue)
G0	Project Sign Off	onshore PM	1. SOW/Scope Statement 2. Project Charter 3. Stakeholder Register 4. Project Site Locations	Onshore PM, Project Sponsor, Development Head, Offshore PM
G1	Project Kick Off	Offshore PM	1a. WBS/Task List 1b. Project Plan/Schedule 2. Signed Off FRS 3. RTVM 4. Team Allocation 5.  Risk Assessment Meeting 6. Project Management Plan 7. Dev/Beta/Staging Refresh from Prod 8. Project Kick-Off Meeting (Full Project Team)	Development Head, Offshore PM, Onshore PM,Technical Lead, DBA
G2	Design Complete	Offshore PM	1. RTVM 2a. Approved HLD/LLD 2b. Process Flow Diagram(s) 2c. Data Flow Diagram(s) 2d. Wireframes, Samples/Mock-ups, Prototype(s)3. Updated Project Plan 4. Issue & Risk Register Updates 5. Test Plan 6. Design Review Meeting	Onshore PM, Offshore PM, Development Head, Technical Leads, DBA, Client
G3a	Coding Complete	Offshore PM	1. Updated HLD/TDD 2. Updated Project Plan/Schedule 3. Build Promoted to Beta 4. IT and System Test Scenarios and Test Cases Ready 5. Updated RTVM 6. Issue & Risk Register Updates 7. Code Review Meeting	Offshore PM, Development Head, Onshore PM,Technical Lead, DBA
G3b	Integration(Staging) Complete	Offshore PM	1. Updated Project Plan/Schedule 2. IT tested Build 3. IT Exit Report/Completed Test Cases(Dev team) 4. Updated System Test Cases 5. Implementation Review 6. Defect Tracking Sheet 7. Updated RTVM 8. Release Checklist(Dev team) 9. Issue & Risk Register Updates	Delivery Head, Offshore PM, ONSHORE PM, Technical Lead, DBA
G4	System Test Complete	Offshore PM	1. Updated Project Plan/Schedule 2. System Test Exit Report/Completed Test Cases 3. Updated Defect Tracking Sheet 4. Updated RTVM 5. Implementation Plan– Draft 6. Build Promoted to Staging 7. Issue & Risk Register Updates 8. UAT Preview	Delivery Head, Offshore PM, Onshore  PM, Technical Lead, DBA
G5a	UAT Complete	Onshore PM	1. Updated Project Plan 2. UAT Exit Report 3. Updated Defect Tracking Sheet 4. Updated RTVM 5. Implementation Plan– Final 6. Final Build Promoted to Beta/Staging 7. Signed Release Acceptance Document 8. Updated Issue & Risk Register 9. Go/No-Go Meeting (Full Project Team)	Onshore PM, Client, Development Head, Offshore PM, Technical Lead, DBA, Project Sponsor
G5b	GOLIVE	Onshore PM	1. Customer Issue Tracker 2. Updated Defect Tracking Sheet 3. Updated Issue & Risk Register 4. Build Deployed to Production 5. Updated RFC Record 6. Project Close-Out	Onshore PM, Offshore PM, Development Head, Technical Lead, DBA

Project Control Book

To store and control the outcome documents of above given process and gates, a Project Control Book should be created as shared repository which will reside inside every project folder and will store the deliverables of every gate. The idea is to have the updated latest version of any deliverable available at a single location at any given point of time.