18 Essential Project Management Consulting Interview Questions *

There are some conditions where Waterfall Project Management would be advantageous over Agile:

• The project is small and requirements are well-defined.
• The project involves repetitive tasks.
• The project will be replicated in the future with the same scope.
• When working with legacy systems, which are not likely to change.
• When the cost of failure is too high and the organization is risk averse.

Burndown and burnup charts are two types of graphs that project managers use to track and communicate the progress of their projects.

A burndown chart shows how much work is remaining to be done in the project backlog. The beginning of the burndown chart marks how many story points are dedicated to the backlog, and then over time those points are reduced before all of them are completed.

A burnup chart is sort of the opposite of the burndown chart and it shows how much work has been completed, and the total amount of work. It could be especially useful if scope would change in the middle of the sprint, because it’s easier to visualize it.

These charts are particularly widely used in Agile Project Management; however, these charts can be applied to any project containing measurable progress over time.

A Work Breakdown Structure (WBS) according to Project Management Body of Knowledge is:

“A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.”

The two main elements of a WBS are:

1. It defines 100% of the work that needs to be done.
2. It breaks down large tasks into smaller ones and displays them in hierarchical levels.

Quality assurance (QA) is related to the process of preventing defects. Quality control (QC) is related to the process of identifying defects. Let’s take two examples to illustrate this:

1. Using a spellchecker while writing some text is a form of QA. Having someone review your text is a form of QC.
2. Writing automated tests during development is a form of QA. Manually inspecting new features in a testing environment is a form of QC.

If multiple teams work on one product backlog, they could use the same reference stories for their estimations. In doing so, it would be possible to make a forecast based on each team’s velocity.

However, if they work on different product backlogs, there is no value in comparison because velocity depends on various factors in different teams (sprint length, team makeup, sizing nomenclature, product). When teams are compared to each other, they respond to peer pressure by gradually inflating the story points that they assign to stories, which leads to unnecessary competition and inaccurate estimations.

Developing software is a complex task, especially if you are working on new features. A lot of the time, the developers are not able to guess with high certainty how many hours a task will take to complete. Using man hours to estimate tasks will often result in over- or underestimations.

The other downside is that more abstract measuring units, like story points, allow developers to have relative estimations of the same task, irrespective of how experienced they are as a developer. A junior and a senior developer might agree that a new task is twice as difficult, as the previous one, but it does not mean they will take the same amount of time to deliver it. You lose this ability for relative comparison between developers with different levels of experience when estimating in man hours.

Milestones. The Waterfall approach assumes that work has been planned in advance and a schedule with milestones was created. The schedule is the most important thing to track for a Waterfall project manager as it quickly shows if the team is on track to deliver a project in time. If the team is a bit late for one milestone, then that might not be a problem. However, if the team is persistently missing the deadlines, then the project manager should intervene to figure out if there are any problems with team progress or with the schedule itself.

Budget burndown. Keeping track of the budget allocations and spending is critical in Waterfall, especially if you are outsourcing some work or relying on third parties in some way. At the end of the day, a project manager in a Waterfall setting is evaluated for their ability to deliver project on time and within budget.

A backlog is a collection of all of our requirements at the current point in time. Even though our backlog can be prioritized, we will never know for sure how difficult each item is until we get to the planning stage. In that stage, we estimate each of those items in relation to the current state of software and our team at that particular time. Therefore, the backlog itself is only a list of “wishes” which can’t be accurately measured in terms of story points until those stories are considered for a sprint. At the same time, a backlog can change in scope constantly as new stories are added or irrelevant ones are removed.

It would be more accurate to compare the number of stories completed to the number of stories in a release backlog, which is an estimated and prioritized subset of the whole backlog. A release backlog is a collection of stories, estimated to be delivered over some time via multiple sprints. If new stories are added, they go into the full backlog and only make it into the release backlog via trade-offs with commited stories.

There is no one model answer for this question; however, a PM should mention some of the most important skills and characteristics:

Communication skills. A PM should have great written and oral communication skills. Most of the daily tasks of a project manager will involve some sort of communication with different stakeholders or team members, either through presentations, emails, or meetings. Successful PMs are empathetic, informative, and clear when communicating or negotiating.

Organizational and planning skills. Project managers often have to juggle different tasks at the same time. They not only need to stay on top of their work but also plan the work for their team. Defining, structuring, and planning work for yourself and your team is one of the key skills you should have as a project manager.

Leadership skills. Staying calm and collected, lifting other people up, and making the team work as a team. A project manager should be able to lead from both strategic and operative perspectives, to take ownership of the project, to motivate and inspire the team and provide a roadmap for their success. A good leader synthesizes information and knowledge to achieve the solutions quickly and calmly.

Risk management. A project manager should have good risk management skills to identify the risks on the project. Identifying and managing risks is a key skill because it helps to prevent unexpected project failures, and to maintain the direction of the project.

Domain knowledge. a good understanding of the project’s field allows a project manager to understand possibilities and limitations of the project technologies and to communicate intelligently with everyone involved in the project.

Knowledge of methodologies. A project manager should know a wide range of methodologies and frameworks to choose from when running a project. They should be familiar with Waterfall, Agile, Kanban, Lean, SAFe and other project management methodologies, because this helps them to better execute the project and select the right methodology to run the project with.

Sprint burndown. The burndown chart shows the number of story points left to deliver versus time left in the current sprint. The burndown can reveal if a team is commiting to few or too many items into the sprint. It also works as a call to action for the Scrum master to investigate impediments if the burndown plateaus. Lastly, it serves as a mobilizing and motivating metric for the whole team to deliver their goals.

Velocity. The goal is to stabilize this metric and keep it consistent through sprints. Velocity shows the teams capability to deliver tasks. The fact that it is constant does not mean that the team is stagnant. Their improvement is factored into their estimations, which become smaller as the team accrues project knowledge and develops working patterns.

Throughput. This metric tracks the number of cards delivered or resolved over the same period, and it is a primary measure of progress. The cards might differ in size but it should balance itself out if an appropriate comparison period is selected. If it doesn’t, then you might need to investigate if there are any flaws in the process of breaking down tasks into cards. Mature Kanban teams are able to create cards of relatively similar sizes.

Cycle time. This metrics tracks how long a card stays as work in progress (WIP) or how long it takes to for a card to go through all the columns in the Kanban board once it is picked up by a team member. A good Kanban project manager should be able to make this process more efficient.

First of all, if this was not done previously, you should initiate high-level estimation meetings with your team to estimate the scope of the project. These estimations then have to be compared to the predefined schedule of the project to see if they match. If they don’t, you will need to contact your project sponsor and/or client to resolve this misalignment.

Secondly, you should prioritize the project deliverables using the MoSCoW method. It sorts all the items into “Must/Should/Could/Would deliver” groups and outlines a clear priority of different items. Start working on the highest priority items in the first sprints. If the project runs over schedule, the impact will be minimized because the most importants will have been shipped already.

Lastly, most fixed-price projects have a predefined scope, however, you can use Agile to your advantage here. Usually, clients come up with new ideas and realizations as they start testing the first iterations of the product. Allow the client to insert new deliverables if they agree to remove items currently in the backlog of the same size.

The key here is to look for communication overlap, i.e., situations where the same communication channel can be used for multiple stakeholders. The exact answer depends on the types of these stakeholders in your situation, but here are a few scenarios that show communication overlap:

• Internal stakeholders from different departments could be communicated with using the same mailing list, Skype group, Slack channel etc. If possible, make this free to join for anyone from within the company (like a Slack channel or a Yammer group), to reduce communication overhead.
• In some cases, communication with clients can happen in public forums, open Slack communities, Facebook groups, newsletters, webinars, etc.

In a typical project, at least half of the 14 stakeholders should fall into one or more overlapping groups. The others might need one-on-one communications channels (email, messaging apps, meetings). A RACI matrix helps to split stakeholders into four roles: those who responsible, those who are accountable, those who need to be consulted, and those who only need to be informed.

Before making any final decisions, there are few steps you could take as a PM to improve this situation.

Ask and Listen. This is the crucial first step. We want to find out the reasons behind the under delivery and how to solve them. Talk 20% of the time, and listen 80%. Let the team member express themself and their frustrations. Figure out the reasons for their underperformance. If possible, try and solve these issues, if the issues are in the team member’s behavior rather than outside their control, move to the next step.

Explain and Remind. This is the step where you explain the behavior you want to change, and why you want it changed. Explain again the overall strategy and plans for the company and the team, and what roles each individual has. Be specific about what needs to change and how this would positively impact everyone. Work with the team member to set SMART (Specific, Measurable, Achievable, Relevant, Time-framed) performance goals for improvement.

Discuss and Appreciate. In this step, make sure you reinforce any good change of behavior the employee shows with their progress. Also discuss the change that happened and how it positively impacted the team and the project. Re-evaluate the SMART performance goals and set new ones once once these are achieved to encourage further improvement.

Reduce management overhead. Make sure that your team members know who they report to and that none of them have more than one manager they have to report to. Complex management structures create overhead, and Waterfall projects are extremely susceptible to this problem if multiple people report to multiple different individuals.

Reduce unnecessary communication. Eliminating needless meetings and streamlining communication process can help any team to increase its performance in Waterfall. Due to the fact that Waterfall projects tend to have decision-makers who are responsible for the critical path of the project it is good to reduce the amount of extra work they are required to do so they can focus on their primary task at hand and unblock the whole team.

Switch to Agile. Certain Waterfall projects would benefit from switching to Agile methodology. In certain projects, especially software delivery ones, this can greatly improve the performance of your team and their output by employing all the Agile best practices.

Kick-off meeting. It’s hard to get to know everyone on the remote team when you are only communicating through the remote tools. Therefore, it’s a good idea to set up a kick-off meeting where everyone could introduce themselves over the web chat and get to talk less formally about themselves. This increases the trust within the team and helps to build better relationships between team members.

Defining communication and reporting guidelines. Transparency and communication are key pillars when building a remote team. This helps all the stakeholders involved to feel informed and allows the team to build trust. Therefore, it is key to define communication guidelines and reporting guidelines as early as possible when starting a project. This will set clear expectations that everyone can adhere to and will prevent a lot of trust issues that could arise otherwise. For example, a manager, could set up a daily Scrum meeting, make sure that everyone in team uses a standardized tool such as Slack for daily reporting, and set up some time to have periodical 1-on-1 meetings with remote team members. If done at the startm this will ensure that everyone will have a clear understanding of the level of communication expected by the PM and stakeholders and will adhere to it.

Focus on the real business value. Agile methodologies often stress using user stories with acceptance criteria to define product features. This makes sure that the team is still solving the needs of real users instead of just trying to finish the list of requirements.

Constant feedback loop. Also in Agile development, testing is integrated into the development. This enables periodical tests to see that the product is working during the development. This way each feature incrementally delivers a piece of working software. This provides the opportunity to test software after each sprint, gaining valuable feedback early in the project and providing the ability to make changes as needed.

Higher product quality and user satisfaction. An Agile way of delivering software has proven to be more effective in achieving higher user satisfaction and overall product quality. If any issues are found during sprint retrospectives, this process enables the team to continuously improve processes and work until the problems are fixed.

Reduced risks of building the wrong thing. Doing incremental runs of software development and showcasing them to the stakeholders reduced the risk of building the wrong solution all together, and it reduced the costs in case the whole project is canceled.

Increased transparency and predictability. Having more exposure and involvement into the project, stakeholders feel they have more transparency and predictability over the whole project. This enables more trust within the organization running the project and more visibility for when the project is over.

The Agile framework defines scope as a variable constraint rather than a fixed one. In an Agile project, scope creep is really a problem caused by injecting new or unplanned work into the middle of an iteration rather than adding scope to the overall project.

All Agile frameworks solve this type of scope creep through formal processes and ceremonies. For example in Scrum, new work should only be introduced during sprint planning rather than in the middle of the sprint. The product owner should lead the prioritization of new work added to the project, always thinking about the relevant project and business goals.

A good PM needs to see where change control becomes a scope creep and make sure that this risk is managed well. The best way to do it is to make the cost of the scope change visible to all the stakeholders so they can make the informed decisions about adding new features.