Information System Contingency Plan (ISCP)

• An Information System Contingency Plan (ISCP) is a pre-established plan for restoration of the services of a given information system after a disruption.

https://en.wikipedia.org/wiki/Information_System_Contingency_Plan

Statement of Work (SOW)

• Definition

statement of work (SOW)
A statement of work (SOW), in project management, is a document in which a contracting officer or chief procurement officer (CPO) specifies the objectives and deliverables for a particular project or service contract. An SOW is often included as part of a request for proposal (RFP), a document used to solicit sealed bids from potential vendors and service providers.


What is included in a statement of work document

Background- This section of a statement of work explains the context for the project and documents the project's overarching goals and requirements
Purpose/objectives- This sections states the project’s overarching goals and how they will solve business problems or positively affect different parts of the organization.
Scope of work- This section of an SOW will document what work will be performed under a contractual agreement, how the work will be divided and who is responsible for completing the work
Tasking and deliverables- This section defines the specific tasks or deliverables the contractor must perform, along with a timeline for work to be completed.
Standards and testing- This section outlines any industry or compliance standards that must be met when executing the project as well as any testing that needs to be done.
Acceptance criteria- This section specifies how the customer will determine whether or not the contractor or service provider has met the objectives of project tasks and deliverables.
Payment- This section documents how and when completed work will be invoiced and when payment will be scheduled.

There are three common types of SOW documents.
Design/detail- This model of SOW focuses on the details behind the project requirements and processes
Level of effort/time and materials/unit rate- This is the most common version of the SOW that is typically used as a template for most projects
Performance- This type of SOW is performance-based and focuses on the purpose and ends results of the project.

https://searchitchannel.techtarget.com/definition/statement-of-work-SOW

• What is a Statement of Work?

A Statement of Work (SOW) is a document within a contract that describes the work requirements for a specific project along with its performance and design expectations.
The main purpose of the SOW is to define the liabilities, responsibilities and work agreements between two parties, usually clients and service providers.

A well-written SOW will define the scope and Key Performance Indicators (KPIs) for the agreement.
These KPIs can then be used as a baseline to determine whether the service provider has met conditions of the SOW.

https://www.villanovau.com/resources/contract-management/what-is-statement-of-work/

• What Is a Statement of Work?

The SoW is the document that captures and defines all aspects of your project. You’ll note the activities, deliverables and the timetable for the project.

What Is the Use of a Statement of Work?
As noted, the statement of work is a detailed overview of the project in all its dimensions. It’s also a way to share what the project entails with those who are working on the project, whether they are collaborating or are contracted to work on the project. This includes vendors and contractors who are bidding to work on the project

It’s also helpful to the project leader, as it provides a structure on which the project plan can be built on. The statement of work will also help to avoid conflicts in the project. With detail and clarity, the SoW helps keep everyone that’s involved in the project on the same page and works to leave confusion to a minimum.

Different Examples of a Statement of Work
There are three main types

Design/Detail: When you’re writing this SoW what you’re doing is conveying to the supplier how you want the work done. What are the buyer requirements that will control the supplier’s process?

Level of Effort/Time and Materials/Unit Rate: This is an almost universal version and it can apply to most projects. What it defines is hourly service as well as those materials required to perform the tasks. It tends to find use in short-term contracts.

Performance-Based: This is the preferred SoW of project managers as it focuses on the purpose of the project, the resources and the quality level expected of the deliverables. It does not, however, explain how someone supposes the work to get done. This allows a great deal of autonomy on how to get to an outcome without requiring a specific process.

https://www.projectmanager.com/blog/statement-work-definition-examples

Requirements Capture

• Requirements Capture is the process of analysing and identifying the requirements of a system and often involves a series of facilitated workshops attended by stakeholders of the system.

http://dthomas-software.co.uk/consulting/requirements-analysis-consulting/

• User Requirements Capture is a research exercise that is undertaken early in a project life cycle to establish and qualify the scope of the project. The aim of the research is to understand the product from a user's perspective, and to establish users' common needs and expectations. The user requirements capture is useful for projects that have a lack of focus or to validate the existing project scope. The research provides an independent user perspective when a project has been created purely to fulfil a business need. The requirements capture findings are then used to balance the business goals with the user needs to ensure the project is a success

https://www.projectsmart.co.uk/what-is-user-requirements-capture.php

Structured Problem Solving Techniques

• Life Data Analysis (Weibull Analysis)

An Overview of Basic Concepts
In life data analysis (also called "Weibull analysis"), the practitioner attempts to make predictions about the life of all products in the population by fitting a statistical distribution to life data from a representative sample of units. The parameterized distribution for the data set can then be used to estimate important life characteristics of the product such as reliability or probability of failure at a specific time, the mean life and the failure rate. Life data analysis requires the practitioner to:

Gather life data for the product.
Select a lifetime distribution that will fit the data and model the life of the product.
Estimate the parameters that will fit the distribution to the data.
Generate plots and results that estimate the life characteristics of the product, such as the reliability or mean life.

https://www.weibull.com/basics/lifedata.htm

• Fault tree analysis (FTA) is a top-down, deductive failure analysis in which an undesired state of a system is analyzed using Boolean logic to combine a series of lower-level events. This analysis method is mainly used in the fields of safety engineering and reliability engineering to understand how systems can fail, to identify the best ways to reduce risk or to determine (or get a feeling for) event rates of a safety accident or a particular system level (functional) failure

https://en.wikipedia.org/wiki/Fault_tree_analysis


The fault tree analysis (FTA) was first introduced by Bell Laboratories and is one of the most widely used methods in system reliability, maintainability and safety analysis. It is a deductive procedure used to determine the various combinations of hardware and software failures and human errors that could cause undesired events (referred to as top events) at the system level.

Fault tree construction
To do a comprehensive FTA, follow these steps:

Define the fault condition, and write down the top level failure.
Using technical information and professional judgments, determine the possible reasons for the failure to occur. Remember, these are level two elements because they fall just below the top level failure in the tree.
Continue to break down each element with additional gates to lower levels. Consider the relationships between the elements to help you decide whether to use an "and" or an "or" logic gate.
Finalize and review the complete diagram. The chain can only be terminated in a basic fault: human, hardware or software.
If possible, evaluate the probability of occurrence for each of the lowest level elements and calculate the statistical probabilities from the bottom up.
http://asq.org/quality-progress/2002/03/problem-solving/what-is-a-fault-tree-analysis.html

• when a problem occurs, you drill down to its root cause by asking "why?" five times.

Then, when a counter-measure becomes apparent, you follow it through to prevent the issue from recurring.

The 5 Whys uses "counter-measures," rather than solutions. A counter-measure is an action or set of actions that seeks to prevent the problem arising again, while a solution may just seek to deal with the symptom. As such, counter-measures are more robust, and will more likely prevent the problem from recurring.

You can use 5 Whys for troubleshooting, quality improvement and problem solving, but it is most effective when used to resolve simple or moderately difficult problems.

5 Whys is an iterative interrogative technique used to explore the cause-and-effect relationships underlying a particular problem

The vehicle will not start. (the problem)

Why? - The battery is dead. (First why)

Why? - The alternator is not functioning. (Second why)

Why? - The alternator belt has broken. (Third why)

Why? - The alternator belt was well beyond its useful service life and not replaced. (Fourth why)

Why? - The vehicle was not maintained according to the recommended service schedule. (Fifth why, a root cause)

Two primary techniques are used to perform a 5 Whys analysis:

the fishbone (or Ishikawa) diagram

a tabular format

These tools allow for analysis to be branched in order to provide multiple root causes.

Criticism

Tendency for investigators to stop at symptoms rather than going on to lower-level root causes.

Inability to go beyond the investigator's current knowledge - cannot find causes that they do not already know.

Lack of support to help the investigator ask the right "why" questions.

Results are not repeatable - different people using 5 Whys come up with different causes for the same problem.

Tendency to isolate a single root cause, whereas each question could elicit many different root causes.

https://en.wikipedia.org/wiki/5_Whys

https://www.mindtools.com/pages/article/newTMC_5W.htm

• When Should I Use Structured Problem Solving?

It is important to use the right tool for the task at hand. This is a powerful method that takes some time to plan and use. As a result, it only makes sense to use it on medium or large problems.Finally, this process is useful to apply when you are facing an unfamiliar or frustrating problem.

The 6 Step Process For Problem Solving

Step 1: Identify the problem

2. Structure the problem

3. Develop solutions

4. Select a solution to the problem

5. Implement a solution

6. Monitor for success

http://projectmanagementhacks.com/how-to-use-structured-problem-solving/

• five problem-solving tools that can each be used to look at a particular problem from a different perspective

1-Six-Step Problem Solving Model 

Each step must be completed before moving on to the next step. However, the steps are repeatable. At any point the group can return to an earlier step, and proceed from there

The process is one of continuous improvement. The goal is not to solve but

to evolve, adjusting the solution continually as new challenges emerge,

through repeating the Six Step Process. 

Step One: Define the Problem

At this stage groups will use techniques such as:  Brainstorming  Interviewing  Questionnaires

Step Two: Determine the Root Cause(s) of the Problem

In this step the problem solving team will use tools such as:  Fishbone diagrams  Pareto analysis  Affinity diagrams

Step Three: Develop Alternative Solutions 

Techniques include:  Force field analysis  SWOT  Porters five forces 

Step Five: Implement the Solution 

The group may use tools, such as a Gantt chart, timeline or log frame 

2-The Drill Down Technique 

 Drill down is a simple technique for breaking complex problems down into progressively smaller parts. 

- Start by writing the problem down on the left-hand side of a large sheet of paper. 

- On the right of each point, write down the points that make up the next level of detail. 

- Repeat this process, for each new point that you identify. 

- Keep on drilling down until you have identified all of the factors contributing to the original problem. 

- This technique can be used in conjunction with the 5 Why Analysis to ensure that you investigate each aspect of the problem.

You can choose to work through this process either on your computer or with a pen on a piece of paper;

To start, write down the problem that you are facing in big letters at the top of the page. Try to sum up the problem in just a word or a short phrase, even if it is complicated in nature.

you are going to break down the problem into three to five smaller issues that make up the big problem.

This process will continue until you simply can’t drill down any farther. Once you have reached what you consider to be the bottom of your chart, you will be finished and you can begin to look for solutions among what you have created.

Specifically, the five whys method matches up with this line of thinking in a number of ways. Both methods are focused on getting to the heart of the problem rather than just fixing the top level issue, and both methods ask you to think about the operation of your business as a whole, instead of just the factors immediately related to the problem in front of you.

3-The Four Frame Model

The Four Frame Model is designed to help you understand and approach issues about organizational problems, development, and change.

It views organizations in four frames representing separate metaphors: structural (factories or machines), human resource (personal relationships), political (jungles or battles for power), and symbolic (theatre or drama). 

Each of these frames can be thought of as a different perspective or way of looking at things, which can help you to see the same situation in a variety of ways. 

The structural frame focuses on the architecture of the organization. This includes goals, structure, technology, roles and relationships. 

The human resource frame emphasizes individual needs, feelings, fears, prejudices, skills, and development opportunities. 

The political frame emphasizes power and competition, taking into account diverse beliefs, interests, behaviors, and skills.

The symbolic frame treats organizations as theatre or drama focusing on meaning and faith. 

With each of the four frames, the interested organizational observer can view the same situation in at least four ways. 

4-The Eight Disciplines Problem Solving

The Eight Disciplines Problem Solving procedure is focused on product and process improvement, its purpose is to identify, correct, and eliminate recurring problems.

It aims to establish a permanent corrective action based on fixing the origin of the problem by determining the root cause. 

Once a problem has been recognized, the 8 disciplines used to solve; 

Team Formation, Problem Description, Implementing Interim Containment Actions, Defining Problem Root Causes, Developing Permanent Corrective Actions, Implementing Permanent Corrective Actions, Preventing Reoccurrences, and Recognizing and Congratulating the Team.  

Once the problem has been resolved, the team should publish and release a final report along with lessons learned. 

5-The Cynefin Framework

The Cynefin Framework helps you figure out how you should be thinking about a problem rather than providing a method for solving it.

The core of this framework is the way that it breaks down problems into one of five contexts. 

The idea is to place the problem that you are facing into one of these specific contexts, which will then help you decide how that problem needs to be approached. 

The five contexts are: Obvious, Complicated, Complex, Chaotic and Disorder. 

Obvious: Are self-explanatory and the cause and effect relationships that you need to uncover are right there for you to see.

Complicated: Are those that are usually best left to experts in the specific field in question. 

Complex: Might not have a clear solution at the present time. You don’t necessarily need an expert in order to solve this problem; you may just need more time and information. 

Chaotic: There is no obvious connection between cause and effect. Once action has been taken and the problem has been mitigated as thoroughly as possible, you can then work toward removing the chaos and gaining a better understanding of what is going on. 

Disorder: The state of not knowing what type of causality exists, in which state people will revert to their own comfort zone in making a decision. 

Once you identify where in this framework your problems are found, you can then start to solve them using a variety of other means and methods. 

http://www.free-management-ebooks.com/dldebk-pdf/fme-top-5-problem-solving-tools.pdf

• a conceptual framework used to aid decision-making

it has been described as a "sense-making device"

Cynefin is a Welsh word for habitat

Cynefin offers five decision-making contexts or "domains"—obvious (known until 2014 as simple)

complicated, complex, chaotic, and disorder—that help managers to identify how they perceive situations and make sense of their own and other people's behaviour.

https://en.wikipedia.org/wiki/Cynefin_framework

• Non-abstract Large System Design Interview Preparation (My Path to SRM)

NALSD describes a skill critical to SRE: the ability to assess, design, and evaluate large systems. Practically, NALSD combines elements of capacity planning, component isolation, and graceful system degradation that are crucial to highly available production systems.

Google SREs are expected to be able to start resource planning with a basic whiteboard diagram of a system, think through the various scaling and failure domains, and focus their design into a concrete proposal for resources

    Design an image sharing service like Imgur and come up with a bill of materials for serving 50.000 Queries per second (QPS).

    Design a log ingestion service like Stackdriver including indexing pipeline and frontend. Highlight the tradeoff differences of the components.

    Design an approach to distributed rate limiting of an API that can handle one million QPS hitting the API endpoints. Optimize for less cross-regional bandwidth and come up with a reasonable bill of materials.

https://danrl.com/blog/2019/path-to-srm-nalsd/

• Introducing Non-Abstract Large System Design

By following an iterative style of system design and implementation, we arrive at robust and scalable designs with low operational costs. We call this style Non-Abstract Large System Design (NALSD). 

NALSD describes a skill critical to SRE: the ability to assess, design, and evaluate large systems. Practically, NALSD combines elements of capacity planning, component isolation, and graceful system degradation that are crucial to highly available production systems. Google SREs are expected to be able to start resource planning with a basic whiteboard diagram of a system, think through the various scaling and failure domains, and focus their design into a concrete proposal for resources. Because these systems change over time, it’s vitally important that an SRE is able to analyze and evaluate the key aspects of the system design.

Why “Non-Abstract”?

All systems will eventually have to run on real computers in real datacenters using real networks. 

AdWords Example

The Google AdWords service displays text advertisements on Google Web Search. The click-through rate (CTR) metric tells advertisers how well their ads are performing. CTR is the ratio of times the ad is clicked versus the number of times the ad is shown.

Design Process

Google uses an iterative approach to design systems that meet our goals

the NALSD process has two phases, each with two to three questions.

In the basic design phase, we try to invent a design that works in principle. We ask two questions:

Is it possible?

Can we do better?

In the next phase, we try to scale up our basic design—for example, by dramatically increasing a requirement. We ask three questions:

Is it feasible?

Is it resilient?

Can we do better?

With these concepts in mind, let’s walk through the iterative NALSD process.

Initial Requirements

when iterating on the design, we will consider our requirements in terms of SLOs

https://landing.google.com/sre/workbook/chapters/non-abstract-design/

• Implementing SLOs

Service level objectives (SLOs) specify a target level for the reliability of your service.

Why SREs Need SLOs

https://landing.google.com/sre/workbook/chapters/implementing-slos/

• Service Level Terminology

Indicators

An SLI is a service level indicator—a carefully defined quantitative measure of some aspect of the level of service that is provided.

Most services consider request latency—how long it takes to return a response to a request—as a key SLI. Other common SLIs include the error rate, often expressed as a fraction of all requests received, and system throughput, typically measured in requests per second. 

Another kind of SLI important to SREs is availability, or the fraction of the time that a service is usable. It is often defined in terms of the fraction of well-formed requests that succeed, sometimes called yield. (Durability—the likelihood that data will be retained over a long period of time—is equally important for data storage systems.)

For example, availabilities of 99% and 99.999% can be referred to as "2 nines" and "5 nines" availability, respectively, and the current published target for Google Compute Engine availability is “three and a half nines”—99.95% availability.

Objectives

An SLO is a service level objective: a target value or range of values for a service level that is measured by an SLI.

A natural structure for SLOs is thus SLI ≤ target, or lower bound ≤ SLI ≤ upper bound. For example, we might decide that we will return Shakespeare search results "quickly," adopting an SLO that our average search request latency should be less than 100 milliseconds.

Choosing an appropriate SLO is complex. To begin with, you don’t always get to choose its value! For incoming HTTP requests from the outside world to your service, the queries per second (QPS) metric is essentially determined by the desires of your users, and you can’t really set an SLO for that.

Agreements

Finally, SLAs are service level agreements: an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain. The consequences are most easily recognized when they are financial—a rebate or a penalty—but they can take other forms. An easy way to tell the difference between an SLO and an SLA is to ask "what happens if the SLOs aren’t met?

SRE doesn’t typically get involved in constructing SLAs, because SLAs are closely tied to business and product decisions. SRE does, however, get involved in helping to avoid triggering the consequences of missed SLOs. They can also help to define the SLIs: there obviously needs to be an objective way to measure the SLOs in the agreement, or disagreements will arise.

Whether or not a particular service has an SLA, it’s valuable to define SLIs and SLOs and use them to manage the service.

SREs’ core responsibilities aren’t merely to automate “all the things” and hold the pager. Their day-to-day tasks and projects are driven by SLOs: ensuring that SLOs are defended in the short term and that they can be maintained in the medium to long term.SLOs are a tool to help determine what engineering work to prioritize. For example, consider the engineering tradeoffs for two reliability projects: automating rollbacks and moving to a replicated data store. By calculating the estimated impact on our error budget, we can determine which project is most beneficial to our users

https://landing.google.com/sre/sre-book/chapters/service-level-objectives/

Mind Mapping

FreeMind - free mind mapping software 

FreeMind is a premier free mind-mapping software written in Java. The recent development has hopefully turned it into high productivity tool
http://freemind.sourceforge.net/wiki/index.php/Main_Page

• Freemind Free Mind Mapping Software Tutorial Mind Map 

https://www.youtube.com/watch?v=vlUdQTeZiNo

• FreeMind Tutorial 

https://www.youtube.com/watch?v=grut_2cardM

Agile Vs. Lean: Yeah Yeah, What’s the Difference?

• Lean

Lean comes from Lean Manufacturing and is a set of principles for achieving quality, speed & customer alignment
Agile
Agile refers to a set of values and principles put forth in the Agile Manifesto. The Manifesto was a reaction against heavyweight methodologies that were popular, yet crippling software projects from actually doing what they needed to do
http://hackerchick.com/agile-vs-lean-yeah-yeah-whats-the-difference

Cost-Benefit Analysis

• Performing a Cost-Benefit Analysis

Cost-benefit analyses help you to

    Decide whether to undertake a project or decide which of several projects to undertake.

    Frame appropriate project objectives.

    Develop appropriate before and after measures of project success.

    Prepare estimates of the resources required to perform the project work.

Everything gets a dollar value in a cost-benefit analysis
Whenever possible, express benefits and costs in monetary terms to facilitate the assessment of a project’s net value.
Consider costs for all phases of the project. Such costs may be nonrecurring (such as labor, capital investment, and certain operations and services) or recurring (such as changes in personnel, supplies, and materials or maintenance and repair). I


Cost-benefit analysis: Weighing future values today
For example, you may expect to reap benefits for years from a new computer system, but changing technology may make your new system obsolete after only one year.
http://www.dummies.com/how-to/content/performing-a-costbenefit-analysis.html

• How to Do a Cost Analysis

A cost analysis (also called cost-benefit analysis, or CBA) is a detailed outline of the potential risks and gains of a projected venture.

1 Define your CBA's unit of cost  benefit
CBA measures literal cost in terms of money, but, in cases where money is not an issue, CBAs can measure cost in terms of time, energy usage, and more.

2 Itemize the tangible costs of the intended project.
Costs can be one-time events or ongoing expenses

3 Itemize any and all intangible costs.
Usually, CBAs also take into account a project's intangible demands - things like the time and energy required to complete the project.

4 Itemize the projected benefits.

5 Add up and compare the project's costs and benefits
we determine whether the benefits of our project outweigh the costs

6 Calculate a payback time for the venture

7 Use your CBA to inform your decision about whether to pursue your project
if it's not clear that a project can generate additional profit in the long run or pay for itself in a reasonable amount of time, you will probably want to reconsider the project or even scrap it all together.

Software design document

• Software design document

A software design document (SDD) is a written description of a software product, that a software designer writes in order to give a software development team an overall guidance of the architecture of the software project.
There are two kinds of design documents called HLDD (high-level design document) and LLDD (low-level design document).
https://en.wikipedia.org/wiki/Software_design_document

Statement of work

• Statement of work

A statement of work (SOW) is a formal document that captures and defines the work activities, deliverables, and timeline a vendor must execute in performance of specified work for a client. The SOW usually includes detailed requirements and pricing, with standard regulatory and governance terms and conditions.
https://en.wikipedia.org/wiki/Statement_of_work

Frameworx (NGOSS)

• Frameworx (NGOSS)

Frameworx, formerly known as NGOSS or "New Generation Operations Systems and Software" is the TeleManagement Forum’s programme to provide ways to help Communication Service Providers to manage their business.
Frameworx includes a set of principles and technical deliverables.



2 Principles
    2.1 Separation of Business Process from Component Implementation
    2.2 Loosely Coupled Distributed System
    2.3 Shared Information Model
    2.4 Common Communications Infrastructure
    2.5 Contract defined interfaces


3 Technical Deliverables
    3.1 Process Model
    3.2 Shared Information Model
    3.3 Lifecycle Model
    3.4 Contract Specifications
    3.5 Telecom Application Map

https://en.wikipedia.org/wiki/Frameworx

Matrix management

Matrix management
Matrix management is a type of organizational management in which people with similar skills are pooled for work assignments. For example, all engineers may be in one engineering department and report to an engineering manager, but these same engineers may be assigned to different projects and report to a different engineering manager or a project manager while working on that project. Therefore, each engineer may have to work under several managers to get his job done
http://en.wikipedia.org/wiki/Matrix_management

negative float

Basically negative float is the amount of time the project is behind, as determined by the total time for the tasks on the critical path exceeding the time available for the project.  There is only zero or negative float on the critical path; by definition the critical path doesn't have positive float.  Negative float is something you want to fix.

http://www.projectmanagementquestions.com/2538/when-to-use-a-negative-float

Interview Questions for IT Project Managers

Sample Interview Questions for IT Project Managers

1. Say you are the Project Manager for a team which gets an order to implement the company's flagship product to a new country/region for the very first time. What attributes would you consider to successfully establish this product in the region?

I understand the interviewer for looking for an answer which was aroung ROI (Return on investment)


2. A project is implemented, you being the project manager , how would you find that the all requirements stated in the Requirements document have been satisfied ?

Using Tracebility Matrix one can track the requirements.

3. Say you have a team for 4 members, out of these 2 team members are suppose to travel for implementation at a customer site next week. Say these 2 team members resign a day before they are about to travel? How would you handle such a situation?

4. Say you are gathering requirements at a customer site. For one such requirement you are suppose to get the requirements from a vendor who is going to lose his job after this project is implemented and thus this vendor is not cooperating while defining the requirements ? What would be your approach for tackling this situation?

5. What would you be your reaction when a project sponsor adds or keeps adding new requirements during System Integration testing?

6. What key attribitues would you be tracking while implementing a project?

http://infosys-project-manager-interviews.blogspot.com/search/label/Interview%20Q%27s%20for%20Project%20Managers

• Define Project?

A project is a temporary endeavor that is unique with a definite start and an end time with a desired result.

Define Plan?
A plan defines –
• Risks, Resources , Communication
• Scope, Budget, Schedule, Quality

What are the principles of Prince2?
The principles are –
• Manage by stages
• Focus on products
• Manage by exception
• Tailor to suit the project environment
• Continued business justification
• Learn from experience
• Defined roles and responsibilities

https://dvq2z39rr5ipe.cloudfront.net/interview-question/prince2-interview-questions/

Software Project Management Interview Questions

What is project management?

Why are project managers required?

What all activities come under project planning?

Who all are the stakeholders in a project?

How do you initiate projects? What all groups are involved? Is there any formal process adopted in your organization?

What all documents created for the project and their significance?

How do you identify the number of resources required for the project?

How are the efforts estimated in the Project?

What methodology is used for estimations?

What do you understand by project risks?

How are project risks identified? How would you mitigate the same?

How to take care of hardware and software requirement for the project?

What are quality plans? What are the key objectives?

What are SCM plans? What are the key objectives?

What is meant by deviation?

What status reporting mechanism was used in the Project?

Explain project life cycle ?

How many phases are there in software project ?

Explain different software development life cycles ?

What are the contents of project management plan document?

What is a fish bone diagram ? What is Ishikawa diagram ?

What is pareto principle ? What is80/20 principle ?

What tools were used for configuration management?

How do you handle change request? What is internal change request?

What is the software you have used for project management?

What activities are performed while project closure?

What do you understand by defect prevention?

How is software shipment managed in the project?

http://infosys-project-manager-interviews.blogspot.com/search/label/Interview%20Q%27s%20for%20Team%2FProject%20Lead%20and%20Managers

PMBOK guide - Project Management Certification

PMBOK guide - Project Management Certification

The PMBOK guide defines the project management processes as follows

Initiating Process: Defines and authorizes the project

Planning Process: Plans the course of action required to attain project objectives and define the scope of the Project.

Executing Process: Integrates people and other resources to carry out the project plan for the project.

Monitoring and Controlling Process: Regularly measures and monitors the activities of the project so that corrective action can be taken when needed.

Closing Process: Formalize the acceptance of the Project and brings the Project to an orderly end


The responsibilities of a Project Manager across Processes.

Planning Process

· Spend 90% of your time here. Do not rush this phase.
· Prepare to run meetings with various Stakeholders
· Ensure that potential Project Risks/Issues identified and create a
· Risk Management Plan
· Identify Key Project constraints/Assumptions
· Identify and Define Project Team Organization Structure
· Identify list of all the Activities of the Project
· Construct Activity Sequences (Predecessor, Successor relationship)
· Identify the Duration of the each activity
· Determine the Skill requirements by type of work and identify suitable resource for it
· Determine the Costs for Individual Activities
· Define the Customer Quality Expectations
· Define Quality Management Plan for your Project
· Ensure that the Quality Activities of the Project are not overlooked
· Define Communication Management Plan to disseminate Project Information to stakeholders
· Define Procurement Management Plan for software/hardware requirements for your project
· Construct a comprehensive Project Plan by including Communication management/ProcureManagement/Risk/Assumptions/Constraints/Issues/Activities

Executing Process

· Approve all the Change Requests
· Approve the Project Plan
· Direct the technical Team to execute the work as defined in the Project Plan
· Direct the other Organizational interfaces to execute work as defined in the Project Plan
· Acquire Project resources and assign them
· Collect data/Metrics about the Project

Monitoring & Controlling Process

· Monitor Risks and see their Progress using Risk Management Plan
· Monitor each Project activity using the Project plan
· Disseminate Project status information to Stakeholders
· Produce Performance report with regard to Scope, Schedule, Cost, Resources, Quality and Risk
· Look for potential Change Requests and implement them using Change Control Procedure
· Control the Cost (possible using EVA(Earned Value Analysis ))
· Control the Quality by implementing quality review techniques and standards identified in the Quality Management Plan
· Manage the Project Team Members performance, Providing feedback, resolving issues to enhance Project performance
· Manage Stakeholders Expectations and resolve issue

Closing Process

· Formally terminate all activities of the Project
· Hand off the completed Deliverable/Product to Customer
· Release all the Project resources including software/hardware
· Create Lessons Learnt Document and share your experiences
· Archive all the Project Documentation




General Guidelines

· Always “Communicate, Communicate, Communicate”
· Understand Customers Language and give what they want. “No more, No less”
· Provide “True status” of the Project all the times
· Use Tools and Techniques to increase your Team Productivity
· Use Microsoft Project Plan for better planning
· Closely monitor Project Critical Path
· Identify Risks in every Project Phase and discuss them in all the Meetings
· Create a Daily Log for all your activities
· Mentor your Team members
· Success or Failure, You are Accountable


http://infosys-project-manager-interviews.blogspot.com/

The Rule of Seven

The Rule of Seven

A control chart is a line graph that represents measurements of a process performance. The chart also contains the Target Value for the attribute being measured, the upper control limit (UCL) and the Lower Control Limit (LCL).

Rule of seven : In control charts, if there are seven points on one side of mean, then an assignable cause must be found.

http://www.preparepm.com/notes/quality.html

Rough Order of Magnitude

Rough Order of Magnitude
the Rough Order of Magnitude estimate = -50% to +50%.


Rough Order-of-Magnitude (ROM) Estimate of costs and time when Requirements are not specified in the early stages of the project.

he ROM Estimate includes the following project parameters which are the foundation for estimation:
Parameter Explanation
Interval, staff-hours Project may be completed within this range if all Requirements will be within the scope specified by Vision document.
Accuracy, % ROM Estimate is created by three estimators. Accuracy equals to 100% minus the biggest difference between one individual estimate and the mean.
Time estimate, weeks Minimum and maximum duration of the project in weeks.
Retainer Amount of staff-hours required to complete Inception Phase in order to produce detailed Specification and exact project Budget.
KSLOC estimated An estimate of Kilo Software Lines Of Code to be written in the project. We calculate and estimate only hand-written, non-empty, non-comment lines of code.
Unadjusted FPs Function Points as an output parameter from COCOMO-II estimate method. In a simplified approach, function points could be compared with software functions or class methods.
Features, BC/WC/ML List of Features from Vision document that were used by estimators. Best Case (BC), Worst Case (WC), and Most Likely (ML) are the output numbers of three-point estimate method. The numbers are just programming staff-hours by the estimate of programmers.


http://www.technoparkcorp.com/process/cost/rom

plan–do–check–act

PDCA (plan–do–check–act or plan–do–check–adjust) is an iterative four-step management method used in business for the control and continuous improvement of processes and products. It is also known as the Deming circle/cycle/wheel, Shewhart cycle, control circle/cycle, or plan–do–study–act (PDSA). Another version of this PDCA cycle is OPDCA. The added "O" stands for observation or as some versions say "Grasp the current condition."
http://en.wikipedia.org/wiki/PDCA

cost of quality

any activity that helps you find, prevent or fix defects in your products is included in the cost of quality

stakeholder

stakeholder
someone who has invested money into something, or who has some important connection with it, and therefore is affected by its success or failure
http://www.ldoceonline.com/dictionary/stakeholder

a stakeholder is anyone who is affected by the cost, time or scope of your project.