Exclusive Project Management Interview Questions and Answers (49)

PV (Planned Value):- PV is also termed as (BCWS) Budgeted cost of work scheduled. It answers “How much do we plan to spend till this date?”. It’s the total budgeted cost for the project.

AC (Actual Cost):- AC is also termed as ACWP (Actual cost of Work Scheduled). It answers “How much have we actually spent?”.

EV (Earned Value):- EV is also termed as BCWP (Budgeted Cost of Work Performed). It answers “How much work has actually been completed?”.
 

Figure: - PV, AC and EV
 

Many project managers traditionally use only Actual and Planned values. But it’s very much possible that you will not get proper results from the same. For instance consider the project shown in figure ‘Actual and Planned’. The project duration is 5 weeks. According to the planned value graph in Week1 we will spend 600$, in week3 we will spend 3800 $ and on the completion of project it is 6000$.

But we where getting computers at a discounted cost in Week1 itself so we bought the computer. According to plan we are supposed to spend in Week1 750 $ but in actual we have spent 3000$. By comparing with the actual plan value we have concluded that we over budget by 2250 $ in the first week. But that’s not the actual case; in reality we bought the computers on discounted rate. So the graph is showing something really wrong. This issue is solved by using EV (Earned Value).
 

Figure: - Actual and Planned
 

Earned Value measures progress and gives us forecasting, thus giving us an actual measure of the health of the project. For instance see the figure ‘Earned Value’. We have given two views one is the planned value and the other is the earned value. According to the planned value it’s a four week project with 25% (2500 $) work completed on Week1, 50 % (5000$) work completed on Week2 and so on. Now when the project starts executing on Week1 only 20% work is completed which means we have spent 2000$ and on week2 only 30 % work is completed. 2000$ and 3000$ shows the earned value for Week1 and Week2.
 

Figure: - Earned Value
 

Earned Value gives us three metric views for a project.
 

Figure: - Earned Value Metrics
 

Current Progress: - This shows how we are performing in the project.
Forecasting: - Will help us answer how we will do in the project in future.
How will we catch up: - In case the project is moving behind schedule or over budget how do we make up?

Current Progress metrics

Schedule Variance (SV)

Schedule variance is the difference between Earned value and planned value
 

Cost Variance (CV)

Cost variance is the difference between earned value and the actual cost.
 

Cost performance Index (CPI)

CPI is the ratio of Earned value to Actual cost.
 

Schedule performance Index

SPI is the ratio of (Earned Value) EV to (Planned Value) PV.
 

Forecasting

EVA helps us to also forecast our project schedule below is the metrics for the same
 

How will we catch up?
 

This is the third view which EV gives us. If the project is not on schedule how do we catch up with the same?. EV gives us something called as To-Complete performance Index (TCPI). TCPI is in an indication of how much we should perform to meet the project schedule.
 

Let’s take a small sample project. We need to make 400 breads and following is the estimation of the project:-

• We need to make 400 breads.
• It will take 10 hours to make 400 breads.
• Each bread will cost 0.02 $.
• Total cost of making 400 breads is 400 X 0.02 = 8$.
• In one hour we should be able to make 40 breads.

Below graph “Bread Project” shows the planned value and the actual cost graph. According to the planned value in 3 hours we will make 120 breads, in 7 hours we will make 280 breads and finally we will complete the 400 bread target in 10 hours. As the project moves ahead actually in the 3 rd hour we have only completed 80 breads with 3$ spent.
 

Figure: - Bread Project
 

Ok, now that we know the actuals its time to calculate the EV, PV and the AC.

In the 3rd hour below is the analysis.

 

Now it’s the time to calculate the earned value. Below figure ‘Earned Value for Bread’ shows the simplified view of the bread project
 

Figure: - Earned Value for Bread
 

EV (Earned Value) = 80 * 0.02 = 1.6$ (How much work has been completed?). So let’s do all calculations.
 

Dictionary meaning of Agile is quick moving. Now how does that apply to software? Agile development methodology considers software as the most important entity and accepts user requirement changes. Agile advocates that we should accept changes and deliver the same in small releases. Agile accepts change as a norm and encourages constant feedback from the end user.
 

Figure: - Agile
 

Below figure shows how Agile differs in principles from traditional methodologies.
 

Figure: - Change of Agile thinking
 

• It’s not necessary to have hi-fi tools and process but a good team interaction can solve lot of problems.
• Working software is more important than documentation.
• Management should not pay attention to only customer contract rather interact with customer and analyze the requirements.
• In traditional methodologies we pledge to stick our plans but agile says “If the customer wants to change, analyze and change your plan accordingly”.

Below are principles of Agile methodology:-

• Welcome change and adapt to changing requirements
• Working software is the main measure of progress.
• Customer satisfaction is the most important thing and that can be attained by rapid, continuous delivery of useful software
• Day to day meetings between business people and development team is a must.
• Business and developers must work together. Face to face to communication is the most important thing.
• Deliver and update software regularly. In Agile we do not deliver software in one go, but rather we deliver frequently and deliver the important features first.
• Build projects around teams of motivated and trustful people.
• Design and execution should be kept simple.
• Strive for technical excellence in design and execution.
• Allow team to organize themselves.
 

Agile modeling is an approach to the modeling aspects of software development. It’s a practice for modeling and documentation for software systems. In one line

It’s a collection of best practices for software modelling in light-weight manner.
In abstraction we can say it augments other software processes. For instance let’s say your company is using UML and then Agile applies approach practices on UML.For example “Keep things simple” is Agile approach. So it means that we do not need to use all diagrams in our project, use only which are needed. If we summarize then in one word we can say Agile modeling says “Do only what’s needed and nothing more than that”.
 

Figure: - Agile Modeling
 

Agile modeling defines set of practices which can show us the way towards becoming successful Agile modelers. These practices are divided in to two sections one the “Core Principles” and other “Supplementary Principles”. Below figure ‘Agile Model Principles’ shows the same in a pictorial format.
 

Figure: - Agile Model Principles
 

Let’s understand one by one what those principles mean.
 

Core Principles
 

Simplicity: - Do not make complex model keep it simple. When you can explain your team with a pen and paper do not complex it by using modeling tool like rational rose. Do not add complexity to show off something. If the developer understands only flow chart then explain him with a flow chart, if he understand pseudo-code then use pseudo-code and so on. So look at your team what they understand and prepare document in a similar fashion.

Welcome Change: - Requirements grow with time. Users can change the requirements as the project moves ahead. In traditional development cycle you will always hear the word “Freeze the requirement”, this has changed with Agile coming in. In Agile we welcome change and the same is reflected in the project.

Incrementally change: - Nothing can be right at the first place itself. You can categorize your development with “The most required”, “Needed features” and “Luxury features”. In the first phase try to deliver the “The most required” and then incrementally deliver the other features.

Model exists with a purpose: - Model should exist for a purpose and not for the sake of just existing. We should know who our target audience for whom the model is made. For instance if you are making a technical documents it’s for the developers, a power point presentation it’s for the top management and so on. If the model does not have target audience then it should not exist probably. In short “just deliver enough and not more”.

It should be light: - Any document or artifact you create should be also updated over a period of time. So if you make 10 documents then you should note that as the source code changes you also need to update those documents. So make it light as possible. For instance if your technical document is made of all diagrams existing in UML, it becomes important to update all diagrams over a period of time, which is again a pain. So keep it light weight make a simple technical document and update the same when you have logical ends in the project, rather than updating it periodically.

Keep multiple models: - Project issues vary from project to project and the same project behavior can vary from organization to organization. So do not think one model can solve all issues keep yourself flexible and think about multiple models. Depending on situation apply the model. For instance if you are using UML for technical documentation then every diagram in UML can reflect the same aspects in different way. For instance a class diagram shows the static view of project while a flow chart a dynamic view. So keep yourself flexible by using different diagrams and see which best fits your project or the scenario.

Software is the most important thing:- The main goal of a software project is to produce high quality software which can be utilized by your end customer in a effective manner. Many projects end up with bulky documents and management artifacts. Documentation is for the software and not software for the documentation. So any document or activity which does not add value to the project should be questioned and validated.

Get Rapid and regular feedbacks: - Software is finally made for the user. So try to get feedback on regular basis from the end user. Do not work in isolation involve the end user. Work closely with the end customer, get feedback, analyze requirements and try to meet there need.
 

Supplementary principles
 

Content is important than presentation: - The look and feel is not important rather the content or the message to be delivered by the content is important. For instance you can represent project architecture using complex UML diagrams, simple flow chart or by using simple text. It will look fancy that you can draw complex UML diagrams but if the end developer does not understand UML then it ends no where. A simple textual explanation could have met the requirement for communicating your architecture to the end developer / programmer.

Honest and open communication: - Take suggestion, be honest and keep your mind open to new model. Be frank with the top management if your project is behind schedule. An open and free environment in project keeps resources motivated and the project healthy.
 

The main deliverable in Agile is a working software and not documentation. Documentation is a support to get the working software. In traditional delivery cycle lot of documentation where generated in design and requirement phase. But we are sure many of documentation where either created just for the sake of it or it was just created. Below are the some of the key points to make documentation Agile:-

• Before creating any document ask a question do we need it and if we who is the stake holder. Document should exist only if needed and not for the sake of existence.
• The most important thing is we need to create documentation to provide enough data and no more than that. It should be simple and should communicate to stakeholders what it needs to communicate. For instance below figure ‘Agile Documentation’ shows two views for a simple class diagram. In the first view we have shown all the properties for “Customer” and the “Address” class. Now have a look at the second view where we have only shown the broader level view of the classes and relationships between them. The second view is enough and not more. If the developer wants to get in to details we can do that during development.
 

Figure: - Agile documentation
 

• Document only for the current and not for future. In short whatever documentation we require now we should produce and not something we need in the future. Documentation changes its form as it travels through every cycle. For instance in the requirement phase it’s the requirement document, in design it’s the technical documentation and so on. So only think which document you want to create now and not something in the future.
 

Agile is a thinking approach to software development which promises to remove the issues we had with traditional waterfall methodology. In order to implement Agile practically in projects we have various methodologies. Below figure ‘Agile Methodologies’ shows the same in more detailed manner.
 

Figure: - Agile Methodologies
 

Extreme Programming (also termed as XP) is an agile software development methodology. XP focuses on coding of the software. XP has four core values and fourteen principles.

XP has four core values: -

• Communication: - Team should communicate on a regular basis, share information, discuss solutions and so on. Teams who communicate very often are able to solve problems more efficiently. For instance any kind of issues which are resolved in a cryptic fashion send an email to the whole team. This ensures that knowledge is shared with every one and in your absence some other developer can solve the problem.
• Simplicity: - Keep things simple. Either it’s from a process angle, technical angle or from a documentation point of view. An over complicated process or a technical architecture is only calling for problems.
• Feedback: - Regular feedback from end user helps us to keep the project on track. So regular feedbacks should be enabled from end user and testing team.
• Courage: - To bring change or to try something new, needs courage. When you try to bring change in an organization you are faced with huge resistance. Especially when your company is following traditional methodologies applying XP will always be resisted.

From the above four core values 14 principles are derived. Values give a broader level view while the 14 principles go deep in to how to implement XP.

• Rapid feedbacks: - Developers should receive rapid feedbacks from the end user. This avoids confusion in the last minute of delivery. In water fall model feedbacks are received in late intervals. This is minimized in XP.

• Keep it Simple: - Encourage simplicity in project design and process. For instance rather than using complex tools probably simple handwritten flowcharts on board can solve the problem.

• Give incremental changes: - Whenever you update patches and updates, release it in small pieces. If you are updating numerous patches in one go and if there is a defect, it will be difficult to track the same.

• Embrace Change: - Do not be rigid with the customer saying that we have already signed the requirement so we can not change the architecture. End customer or users are finally human beings so they can change as the project moves ahead....Accept it if it’s logical.

• Light Weight: - Keep documentation and process as simple as possible. Do not overdose the developer with unnecessary documentation. Developer’s main work is coding and ensuring that the code is defect free, so he should be more concentrating on the code rather than documentation.

• Deliver Quality: - Any code you deliver should be defect free. Be committed to your work and deliver defect free code.

• Start small and grow big: - Many times the end customer wants to start with a big bang theory. He can start with a big team, wants all the functionalities at the first roll out and so on. Start with small team and the “must have” features to be delivered. As we add features and the work load increases gradually increase your team strength.

• Play to win: - Take all steps which are needed to make a project success. Any type of deadline and commitment try to meet the same with true spirit.

• Encourage honest communication: - Promote honest communication. If communication happens face to face then there is less leakage of requirement. Encourage end user to sit with developers and give feedbacks; this makes your project stronger.

• Conduct testing honestly: - Test plans should not be created for the sake of creation. Test plan should prove actually that you are on track record.

• Adapt according to situation: - No two projects are same, no two organization are same and behavior of people from person to person. So it’s very essential that our approach also adapts according to situations.

• Metric honesty: - Do not gather metrics for the sake of gathering or showing off to external people how many metrics your project derives. Pick metrics which makes sense to your project and helps you measure your project health.

• Accept responsibility: - Do not impose or assign people on task which they do not like. Rather question the resource once which tasks he likes and assign accordingly. This will increase productivity to a huge level and maintains your project enthusiasm high.

• Work with people’s instincts: - Normally in a project team there are highly motivated people, moderately motivated and people with less motivation. So give power to your motivated team members and encourage them.
 

Use story is nothing but end users requirement. What differentiates a user story from a requirement is that they are short and sweet. In one sentence they are just enough and nothing more than that. User story ideally should be written on index cards. Below figure ‘User Story Index Card’ shows the card. Its 3 x 5 inches (8 x 13 cm) card. This will keep your stories as small as possible. Requirement document go in pages. As we are keeping the stories short its simple to read and understand. Traditional requirement documents are verbose and they tend to loose the main requirement of the project.
 

Note: - When I was working in a multinational company I remember first 50 pages of the requirement document having things like history, backtracking, author of the document etc. I was completely drained till I started reading the core requirement.
 

Every story has a title, short description and estimation. We will come to the estimation part later.
 

Note: - Theoretically it’s good to have cards, but in real scenario you will not. We have seen in actual scenario project manager keeping stories in document and every story not more than 15 lines.
 

Figure: - User Story Index Card
 

It’s written and owned by the end customer and no one else.
 

Story is valid if it can be estimated.
 

Test plans are written before writing the code.