Tips on effective project management

I was wondering why 65% of the projects go into trouble and more than 85% of them are never recovered back on track.As a fact of matter, reports have concluded that “it is, basics which were missing in the projects” and we always look out for rocket science solutions.Well, it is always “easier said than done”.Commonsense and street smartness are definitely prerequisites for any work including project management.

Following table highlights basic tips for effective and successful project management

Sr#	Area	Tip
1	Success criteria	How will you know when you are done?
2	Project definition	Clearly define the project, objectives, boundaries, deliverables
3	Stakeholder identification and objectives	External as well internal stakeholders and their prime objectives
4	Roles and responsibility Chart	Take acceptance from all owners and make them speak out their responsibilities
5	Template repository	Keep all Project templates in one repository. Have uniformity
6	Budget tracking	Regular, periodic, provisioning
7>	Project scope and out of scope	Clearly define what’s not. Have a single document for scope
8	Risk management plan	Take it separately, have weekly meetings and monitor if new risks have been identified and old risk are mitigated. Keep track of risk log once a fortnight not to get into risks but to check if Risk management is happening
9	Team involvement in identifying steps required for each project deliverable	Take agreement on time commitment and evaluate against estimates
10	Change management plan	Every change in deliverables, scope, technology, schedule etc should be managed
11	Competency level check	Training plan, mentoring, backups in case
12	Go no-go decision plan	Evaluation Criteria, periodic, documented. (DAR)
13>	Disaster recovery plan	Task force. Identify individuals/groups for crisis situation. Draw demarcation and segregate different situations. Do not involve all teams/members at all the times for all the crisis
14	Requirements management plan	Business to technical to testing requirement mapping and traceability. Update all changes and impacted areas. Maintain requirement change document throughout the project
15	Shorten meeting times	Ideal time is 10 to 20 minutes
16>	Assess status report effectiveness	Check if you get queries, feedback on reports. Is it read? Does it meet all stakeholders expectations (perspective). If not, is it good to make different reports for different stakeholders
17	Test orientation	Should NOT be 1. defect free delivery 2. good testing means highest number of defects
18	Closure	Create an open, safe place for people to give honest and sincere feedback on the project
19	Anonymous survey to your project team	Questions like: What went well on the project? What could have gone better? What would improve your experience on future projects? How could the project leader be more effective?
20>	Sign off, project closure and acceptance	Make sure formal document (one pager) is prepared and sent across to all stakeholders specifying project has been completed and delivered detailing out important scope and its readiness. Take acceptance from all

how to implement Risk based testing methodology process framework

How is risk based testing or RBT methodology implemented in IT Projects

Slide-1 - RBT, Risk Based Testing, Scope and coverage of presentation

RBT, Risk Based Testing is a very flexible process; it can be applied as per the project requirement, in parts, as a whole or for specific goal.

RBT can primarily be used for e.g.

1. Functionality readiness over a period of testing time

2. Testing critical and high priority functionalities early in the phase

3. In case of reduced timelines RBT helps Prioratise testing

4. as a dashboard for testing progress monitoring and control

5. Getting early warning signals

6. Go: no-go decision making based on accurate predictions rather than guess work

7. Giving early deliveries or staggered/iterative deliveries

8. Dashboard for testing effectiveness and senior management view (macro details, business oriented) avoiding micro level details

Slide-2 - Business Challenges and Needs

Slide-3-Risk Based Testing (RBT) Process

At high level RBT process consists of following steps/processe:

1. Identification -

a. Stakeholders and their objectives

b. Factors to be considered for assessment of complexities and Risks (e.g. Functional complexity, new functionality, inexperienced resource, unclear/changing requirements etc)

c. project tasks, functionalities (Break up), activities to be considered for RBT implementation

2. Analysis -

a. evaluates the factors (parameters) and assign constant values to each factor on a scale (preferably 1-10).

b. Assign weights to probability of failure and impact upon failure to Cost, Time & Quality.

c. This is one time activity at project/application level by management, SO etc

d. Take the functional break up and ask Testers/Test Leads to assign weights (Failure probability and Impact on time, Cost and Quality) to individual functionality

3. Risk Exposure Calculation -

a. Calculate total weighted average of each factor as well as each functionality, multiply it by constants and find a product

b. derive % distribution of each function. Assign Risk Exposure Number (REN/RPN) as per defined category. Refer classification table

4. Testing Policy

a. Create complete set of testing techniques to be applied to the project

b. categorize these techniques in 3 classes, basic testing, partial testing and full testing

c. Define the scope of testing for each functionality class based on its RPN value

5. Test Planning

a. Plan the testing activities, Analysis, preparation and Execution based on time distribution given by RBT to each phase/activity

b. Translate total time available to each functionality and further to each scenario/test case.

c. Associate Testing Type to each test scenario/test case

d. Also maintain RPN number for further tracking and monitoring

6. Governance

a. Create a dashboard for progress reporting, Risk monitoring and functionality readiness

b. Populate data from test metrics like testing reports (Planed/Execution, pass/Fail, Defect status etc reports)

c. Calculate % completion through statistically applied formulas

d. Refer prediction model given by RBT for go, no-go decision making

Slide -5- RBT Approach – In Nutshell

The overall picture once RBT methodology is applied to the project.

It shows all the requirement classification in the FMEA (Failure Mode & Effect Analysis) mode.

Lower the probability of failure and lower the impact of this failure, function gets allocated to one of the three categories.

Green ones are the functions which have less risk exposure than the ones in Red.

The monitoring and control is done in RBT not based on tasks or %completion of phase which is a usual practice in Project monitoring and status reporting.

Here we monitor the progress and completeness readiness of each functionality where in its risk exposure is already known and the timeline by which each functionality should be ready is calculated and monitored.

This method gives control over driving the testing efforts, defect fixing efforts so all critical functionalities gets developed, tested and remains stable in QA environment for longer duration. The benefits are illustrated in detail in last 2 slides.

Slide – 5 - Factors and Complexity Calculator

A - Following 3 steps are one time activity for each application or project

Step-1: Identify all the critical factors/parameters applicable/relevant to the project/Application.

Step-2: Arrive at Complexity value (on scale of 1-Least Complex to 5-Very Complex) through brainstorming, involving SO, managers and key project personnel

Step-3: Use the factor values as constants through out the project/Application for all releases.

B- Regular Activity once every release or delivery

Step-4: Involve Testers/Test Leads who would be working on Test preparation and execution. Plot all the functionality in the tool

Step-5: Ask Testers/Test Leads to weigh each function against the identified Factor. (Hide the constant values to avoid influence)

Step-6: Calculate weighted averages and functional complexity values. This is bi-directional. We get for each function total weight against all the factors and secondly, each factors weight age for the release.

Slide -6 - Risk Exposure Calculation

This slide is a alternate and more detailed approach in weighted averages calculation. The first part is continuation to the previous slide.

Step-7: Calculate % weight age distribution of each function. This will give what is the complexity factor value of each function.

Step-8 - Plot the requirements and find the probability of failure of each function against each factor. The scale can be 1-3, 1-5, 1-10.

FMEA - Failure Mode and Effect Analysis is an effective and more accurate way of calculating RPN (Risk Priority Number) or Risk Exposure of each functionality.

Impact is assessed based on the probability of failure value. It need not be necessary that if Higher the probability of failure higher is the impact. In some cases it can be reverse depending upon evaluation criteria.

Step-9 - As done on slide 6, similarly slide 7 demonstrate end to process of risk exposure calculation. First Identify the Probability of failure of each function based on all the factors. Hide the Constant values from testers/Test Leads to avoid influence.

Step-10 - assign the impact value for each function on time, Cost and Quality if the function fails.

Step-11 - Calculate weighted averages and then multiply both weighted averages to get the Risk exposure value for each function. Calculate weight age out of 100%.

Step-12 - Assign Risk Severity number of RPN based on the step-13(Criteria) given in next slide

Slide – 7- RBT based Test Planning and Effort Distribution

Allocate time for test preparation and test execution based on risk exposure or Risk Severity number. The time gets allocated to each requirement accordingly. Higher the RPN more the time allocated.

This is the one of the benefits of RBT, it accurately assigns time based on risk, traditionally we end up spending equal time on all requirements irrespective of the complexity, severity, probability of failure and impacts.

Define Testing Policy:

Testing methodology or testing techniques here are classified into 3 types.

1- Full Test Suite

2-Partial Testing

3- Basic Testing

There are many testing techniques which are used in testing projects. The approach suggested through RBT is lesser the RPN lesser the nature of testing involved.

 

Slide – 8- Testing Policy

The RPN or Risk exposure of a functionality/Requirement can be translated to individual Test scenarios as well as test cases. This is primarily done by Test Leads/Testers during test scenario and test case identification

Point to be mentioned here is that: Particular Requirement may have high Risk Exposure, but test cases for that particular requirement could have different Risk exposure depending upon the nature of the test case. The total Risk exposure % of all test cases associated with a particular requirement should sum to Risk exposure of the requirement.

 

Slide – 9 -RBT – Assessment and Monitoring

Assessment of % readiness/completeness is done mathematically as well as by taking data feeds from testing reports on periodic basis.

Actual % completion/readiness is arrived at and focus areas are highlighted from the beginning of the project itself.

This helps project in many ways

1. Requirements having maximum/critical defects

2. Individual Requirement readiness in %

3. Focus shift required on continuous basis in the areas of development, defect fixes, testing

4. This also drives the testing focus as required and defined in testing policy rather than focusing on all areas equally.

5. This also gives overall consolidated view of testing progress hiding micro level details which most of the times confuses SO/Management

6. Overall project tracking and % readiness (This is not as per phase but as per original business requirement)

Slide – 10- Benefit Illustration 1 – Defect free Delivery of Business Priority Functions

This example illustrates one of the many benefits RBT provides

1. Prioratise deliveries based on readiness, predict successful deliveries well in advance

2. De-scope partial requirements rather than complete release based on accuracy of status given by RBT

3. Deliver agreed requirements defect free without fear of production failures and QA assurances

Focus completing testing on time or before time if the need be through prioritization

Slide – 12 - Case Study 2 – Reliability, Predictability and Optimum Quality Delivery

1. Deliver entire project with accurate status and predictions about open issues, functionalities that works completely

2. Deliver less critical functionalities with open and acceptable defects and rest of the functionalities with 0 Defects

3. Stop focus on less critical items on right time and divert efforts in more critical areas

4. Bring critical functionalities to completion early enough so they remain in QA environments for longer time thus assuring stability