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.

Rules to make the scrum product development successful

Many people always look how to make their scrum projects successful. I am sure that these rules will help them a lot:

1. Identify Full-Time Product Owner
2. Product Owner Works With Team and All Other Stakeholders
3. Product Backlog Created and Managed by Product Owner

4. Daily Scrum Meeting with 3 Questions (Completed? Will Complete? Obstacles?)

5. Daily Scrum Meeting Same Place and Time and Less Than 15 Minutes
6. Regular Sprint Length (no more than 30 days)
7. Sprint Planning Meeting to Create Sprint Backlog of Estimated Tasks
8. Sprint Burndown Chart
9. Team Room with All Needed Equipment and Supplies
10. Retrospective Meeting for Process Improvements
11. Definition of "Done"
12. Commitment Velocity Calculated (from Sprint Backlog Estimates)
13. Team Size 7 +/-2, Maximum of 12
14. Cross-Functional Team Including ScrumMaster and Product Owner
15. Team Self-Organization - Team Members Volunteer for Tasks
16. ScrumMaster Tracking and Removing Obstacles
17. Team Safety - No Interruptions to Team's Work During Sprints
18. No "Break" Between Sprints
19. Sustainable Pace - Timebox Effort, Not Just Schedule
20. Quality is Not Negotiable - Defects Go on Top of Product Backlog

Project Management Methodologies and Software Development Process

There have been a lot of software development process created over the years by different PM practitioners. In “Rapid Development”, most of the companies identifies a number of categories of process - most real-life projects employ a blend of these:

• Pure waterfall
• Code-and-fix
• Spiral
• Modified Waterfalls
• Evolutionary Prototyping
• Staged Delivery
• Evolutionary Delivery
• Design-to-Schedule
• Design-to-Tools
• Commercial Off-the-shelf Software

With the exception of code-and-fix, these processes have a few things in common – they assume that software development is analogous to a defined industrial process; they are based on physical engineering processes; they are predictive; and they assume that people can be treated as abstract resources. “It is typical to adopt the defined (theoretical) modelling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice”

In process control theory, a “defined” process is one that can be designed and run repeatedly with predictable results. In particular, the inputs to the process and the process itself must have very low levels of noise. When a process cannot be defined precisely enough to gurantee predictable results it is known as a “complex” process. Complex processes require an empirical control model. An empirical control model entails frequent inspection and adaptive response.

Software development is not a defined process, at the very least because the main inputs to the process activities are people. Traditional methodologies contain lists of activities and processes that are depicted as reliable and repeatable, however we all know from experience that this isn't the case. Ask two different groups of people to come up with class diagrams from the same requirements and you'll get two quite different results. The problems with treating software development as a defined process are discussed further by Schwaber and Beedle1.

Physical engineering processes consist of distinct phases. Thed esign phase is difficult to predictand requires creativity and imagination. The primary activities in the design phase are intellectual. The design phase is followed by planning for the construction phase, and then by the construction phase itself. The primary activities in the construction phase are physical, and it is much easier to plan and predict than the design phase. In many physical engineering disciplines construction is much bigger in both cost and time than design and planning. For example, when you build a bridge, the cost of design is about 10% of the total job, with the rest being construction.

For the analogy between software development and physical engineering to hold, we need to be able to separate design from construction, be able to produce a predictable schedule, design artefacts that are complete enough for construction to be straightforward, and be able to perform construction with people of lower skills (who are hopefully cheaper to employ). Construction also needs to be sufficiently large in time and effort to make this worthwhile. The situation in software development is quite different. The most of software development companies reports the following breakdown of software development by activity:

1. Analysis 16%
2. Design 17%
3. Code/Unit Test 34%
4. System/Integration Test 18%
5. Documentation 8%
6. Implementation/Install 7%

In an even more extreme analysis proposed by Jack Reeves - he suggests that code is analogous to an engineering design, and that software is “constructed” by running a compiler. Accordingly, the construction stage in a software development project is essentially free.

Regardless of the exact numbers, it's clear that as a percentage of the overall project effort, construction is much less significant in software development than it is in physical engineering. If construction is analogous to coding, our experience indicates that it's very difficult and expensive to

1. “Agile Software Development with Scrum”, Ken Schwaber and Mike Beedle, Prentice Hall, 2002
2. “The New Methodology”, Martin Fowler,http://www.martinfowler.com/articles/newMethodology.html
3. “Worldwide Benchmark Project Report”, Howard Rubin, Rubin Systems Inc., 1995
4. “What is software design?”, Jack Reeves, http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm

produce design artefacts detailed enough for construction to be straightforward. If construction is analogous to compilation, then we can effectively ignore the construction effort. In either case, processes based on analogies with physical engineering should be treated with suspicion.