Thursday, March 31, 2016

Questions That Reveal Everything in Project Management

Some projects are failures from the start. Others look good at the start but it soon becomes clear they're doomed. 

You've probably managed a project that everyone (including yourself) secretly thought was going to fail. When this happens it's in everyone's best interests to candidly voice their concerns. 

Every project entails risk. Every project can fail. Most successful projects encounter dark days when everything seems to go wrong. There's a fine line between being a quitter and recognizing reality. 

The following questions cut to the heart of project health. They may help separate normal project issues from projects that will certainly fail. 

  • Does the organization have the ability to execute the project? 
  • Is the sponsor actively committed to the project? 
  • Does the sponsor have the ability (authority, influence) to support the project? 
  • Are stakeholders resisting the project? 
  • Are expectations about the project close to reality? 
  • Is the project visible to the organization? 
  • Is the project widely resisted at the ground level? 
  • Does the project have support to manage the people-side of change? 
  • Is the project plan overly aggressive (lack of contingency)? 
  • Are requirements consistent with the realities of the business? 
  • Are releases long, big and/or complex? 
  • Is there a realistic plan to integrate the project with concurrent changes to the organization? 
  • Does the risk management plan identify high impact, high probability risks that have been accepted? 
  • Does the quality plan indicate that quality will excessively low?
  • Does the project team have the ability to deliver the project? 
  • Is political infighting causing excessive delays and low quality decisions? 
  • Are project deliverable's low quality? 
  • Does your project approach or plan have structural issues? 
  • Do products being delivered have structural issues (e.g. technology architecture issues)? 
  • Has productivity been chronically low? 
  • Are there serious relationship problems with consultants, vendors and suppliers? 
  • Are issues mounting far faster than they could possibly be cleared? 
  • Is the project team in low spirits? 

Reasons IT Project Fails

IT projects commonly fail at a rate of somewhere between 50% to 80% and here some reasons:

1. Failure to evaluate alternatives 
The business case fails to consider alternative approaches to the project. This exposes the project to challenges later (i.e. why didn't we consider ____ approach?). 

2. Poor financial forecasts 
Financial forecasts in the business case are inaccurate. 

3. Optimism bias renders business case unrealistic 
The business case makes rosy assumptions that don't reflect business realities.

4. Cooked numbers in forecast 
Lack of objective financial analysis. The developer of the business case makes the numbers "work". 

5. Metric based approvals 
Reviewers approve a business case based on a handful of forecast metrics without examining constraints and risks. 

6. Missed future costs 
The business case promises to reduce existing costs but fails to anticipate new costs the project will introduce. For example, a system project may free-up administrative resources but increase the need for system administrators (who are generally more expensive). 

7. No business case 
The project proceeds without a formal analysis of its merit. 

8. Budgeting errors 
A low quality project budget that leads to financial chaos. 

9. Poor risk analysis 
Failure to identify, analyze and communicate risks. 

10. Failure to identify all stakeholders 
The project manager fails to involve IT operations. When it comes time to launch, the head of operations rejects the project. 

11. Optimistic resource assumptions 
The project plan assumes key resources are 100% committed to the project when they have other commitments. 

12. Optimistic estimates 
Estimates that are overly optimistic or fail to consider true project scope. 

13. Coerced estimates 
The project manager directs the team to provide low estimates.

14. Naive estimates 
Those who provide estimates don't have the requisite experience (e. g. the project manager provides estimates for the testing phase). 

15. Rough estimates 
Ballpark estimates are assumed to be rock solid (no formal estimates are produced). 

16. Failure to properly estimate tasks not considered critical 
Tasks that aren't on the critical path such as data migration are severely underestimated. 

17. Poor task scheduling 
The work breakdown structure is missing dependencies. 

18. Big bang releases 
It's well accepted that releasing a project in incremental phases tends to reduce risk and cost. Nevertheless, projects tend to be planned with major releases. 

19. No Methodology 
The project is executed according to an ad-hoc process that's likely to fail.

20. Inadequate requirements 
Unclear requirements that leave too much room for interpretation. In many cases, the project manager or developers end up filling in the blanks. 

21. Gap between requirements and expectations 
Business users begin to dream that the system will do things that aren't captured by the requirements. 

22. Requirements aren't compliant 
Requirements are not in compliance with laws, regulations, standards, best practices or requisite audits. 

23. Silo requirements 
Requirements fail to look at the project at the enterprise level. For example, they fail to consider integration with key business processes. 

24. Naive requirements 
Lack of due diligence in developing and validating requirements (e. g. subject matter experts aren't consulted). 

25. Solution in search of a problem 
The requirements don't solve business problems. 

26. Requirements don't match the business case 
The requirements drift from the original goal of the project. 

27. Requirements dictate architecture 
Requirements specify the solution. For example, specifying that a particular COTS product must be used without proper due diligence. 

28. Inaccurate requirement priorities 
Nice-to-have requirements are classified as high priority. 

Project plan becomes outdated 
The project plan isn't kept up to date during the execution phase. It quickly becomes obsolete and the project essentially runs without a plan. 

30. Tasks aren't tracked 
Schedule slippage isn't addressed until deadlines have passed. The project becomes hopelessly behind schedule and over budget. 

31. Issues aren't managed 
The project manager fails to aggressively escalate and resolve issues. 

32. Scope management failure 
Severe scope creep throws the project into disarray. 

33. Risk realization 
A risk identified in the planning phase is realized. For example, a project plan may identify a heavy dependency on a critical resource. If that resource resigns or becomes ill, the risk is realized and the project may fail. 

34. Financial controls failure 
The project manager fails to control the project budget. 

35. Low performance 
The performance of a key team member fails to meet expectations. 

36. Communication failure 
Project goals, objectives, progress, productivity, quality, risk and constraint information isn't transparent to key stakeholders. Expectations become out of line with project reality. 

37. Low customer satisfaction 
The customers (e. g. project sponsors or users) aren't happy with the project. For example, executives get the perception that the project is out of control. 

38. Business strategy change 
New business priorities lead to project cancellation. 

39. Business environment 
A recession or industry event takes place that triggers project cancellation. 

40. Organizational changes 
Organizational changes disrupt project execution. 

41. Business disruption 
Project launch often requires time from key business talent (e. g. learning a new system or launching new business processes). For this reason, there is sometimes resistance to launch. 

42. Low user adoption 
Users refuse to adopt a new technology or process. 

43. Excessive quality sacrifices 
Business demands a fast, cheap project. They sign off on risks that the project will have quality issues. The result is a low quality product that's unusable. 

44. Negative business results 
A project that's delivered to specifications but the business results don't meet expectations. For example, a new product that decreases sales instead of improving sales. 

45. Force Majeure 
An act of war or nature. 

Loss of sponsorship 
The sponsor changes their mind about the project. 

47. Loss of executive support 
Powers larger than the sponsor step in to stop the project (sponsor lacks support). 

48. Project Infighting 
Interpersonal conflict between team members. 

49. Passive aggressive tactics 
A stakeholder secretly sabotages the project. 

50. Vendor management failure 
Your relationship with a key vendor turns bad and project issues quickly pile up. 

51. Vendor infighting 
The relationship between vendors turns bitter and issues mount. 

Naive technology selection 
Business chooses technologies without understanding the full implications of their decisions. 

53. Inadequate technology evaluation 
Technologies are chosen without a diligent evaluation. 

54. Poor architectural design 
The solution architecture is flawed leading to insurmountable project issues. 

55. IT governance 
IT governance blocks the project. For example, the project duplicates capabilities that already exist. 

56. Loss of key technical resources 
Losing a key resource who has no backup. 

57. Unforeseen technology dependencies 
A technology dependency is identified in the execution phase that delays the project. 

58. Gold plating 
Developers add features to the product that aren't in the requirements. The added complexity escalates project costs or prompts users to reject the product. 

59. Security vulnerabilities 
Security vulnerabilities in a chosen technology trigger unforeseen risks, costs and delays. 

60. Capacity planning failure 
The product fails performance testing and requires hardware or software reworks beyond the project's budget. 

61. Tool breakdown 
Tools (e. g. development tools) are buggy or ineffective leading to delays. 

62. Data quality 
The data migration team discovers that data quality is low. The solution is unusable without major data quality initiatives. 

63. No methodology 
Development follows an adhoc process that's prone to failure. 

64. Inadequate testing 
Testing fails to uncover serious defects that are later detected by users (shaking confidence in the product). 

Friday, March 4, 2016

How to Delay or Derail a Project

Top 15 ways to derail a project--and how to avoid these project management pitfalls

Having a poor or no statement of work
I've seen many projects encounter troubles due to the lack of a well-defined project scope. Despite the best planning efforts, change is inevitable, so having a clear statement of work up front is essential in getting agreement with the customer on what will actually be accomplished. A poorly constructed statement of work (or absence of one) will lead to ambiguities that are hard to resolve and you will never truly know when the project is finished.

Not setting expectations up front. One of the key ways to screw up a project is to not create a road-map and define project requirements and expectations for all stakeholders at the beginning of the project.

That's why "before we start any projects, I make sure that everyone on both the customer team and project team have a clear, documented understanding of two primary things: What we are going to do, and how we know when we are done. Without documented agreement on the answers to these two questions, the project is in danger from the start.

Not securing management buy-in
Executing a project without securing sponsor support is not only counter-productive but also a recipe for disaster. It's imperative to be on the same page with the sponsor for a project to move in the desired direction and get organizational buy-in.

Using the same methodology for all size projects
Most project management methodologies have a standard set of key tasks and deliverable's for enterprise IT projects. Most methodologies are designed around projects of a certain size (i.e., $1 million plus). If you have a project that is $100,000 and you try to use the standard approach, you may find that it costs more to do the deliverable's than it does to do the actual project.

Overloading team members
Your team members are not machines, pay attention to how much work each individual member is assigned. If one member is overloaded, the end product will suffer. Utilize the strengths of your team and spread out the workload as much as possible. This will avoid overwhelming your team.

Waiting or not wanting to share information
In Software Development, waterfall approaches to project delivery--where results are not presented to users and stakeholders until late in the project--introduce risk and often lead to disappointing. That's because "users often don't know what they want until they can actually see, touch and work with it. That's why using an agile, iterative approach to project management is better. Iterative projects delivers results in short, quick phases, with the most critical and complex components delivered first.

Not having a clearly defined decision-making process
While user involvement and feedback are critical, successful projects also need a clear and defined decision-making process. Project teams should embrace change, but change decisions need authoritative approval agreement and documentation. Understanding the process and chain of command keeps everyone reading from the same playbook.

Allowing scope creep (or excessive scope creep)
Loosely defined and unclear project scope, halfway surprises and frequent change requests can lead to increased timelines, increased cost, escalations, a demotivated team and, most importantly, an unsatisfied customer.To combat scope creep, "ensure project objectives are understood, deliverable's are defined and the project is monitored daily. That said, change requests are a fact of life in projects. So it is a good idea to budget for scope creep and have a defined process for accommodating change requests.

Being afraid to say "no." 
Part of being a good project manager is being "an educated advisor". This means knowing when to say 'no' to a request, whether because it's not in the best interest of the company, the project, the end-users or the customers. Knowing how to say no and offering a constructive alternative solution can prevent a project from becoming derailed or delayed.

Not being a team player
Every project has a team that is expected to work together to successfully complete the work. The project manager is the hub of the team, the process and the solution. Yet many young or new project managers make decisions without consulting with the team and without gaining approval. Without that communication and approvals, the project is headed for disaster. The project manager cannot manage a project schedule, budget or scope without the team.

A related danger is that "the project becomes 'our project' rather than a 'company project. Instead of focusing on achieving the goal or getting it right, [team members or whole teams] then spend time looking for others to blame, defending their own position or refusing to co-operate with other teams.

It's like a non-performing sports team where the defense blames the offense; the offense then blames the defense; and the coach berates the referee. They've temporarily forgotten about winning.

Poor communication
One of the primary responsibilities of the project manager is to communicate. Communication keeps everyone on the team up to date with the current status, next steps and any issues. However, too many times projects managers feel they are too busy managing day-to-day tasks to take the time to communicate. This is a critical mistake and often the demise of a project. If the PM does not send out the meeting minutes, status reports and follow-up emails, he/she is increasing the risk for delays, risk for conflict and project failure.

Too many, too long status meetings
Nothing sucks the life out of a team more than a status meeting. Sure, there's some important information in there, but all too often the same information could have easily been shared through a collaborative system. Reserve team meetings for decision-making; for instance, Agile teams have daily 'stand-ups' which are useful in quickly identifying and removing obstacles. 

Not caring about quality--the "good enough" syndrome
Due to different factors, such as schedule or budget pressure, it might be tempting to reduce the effort on quality assurance (QA), however, a lack of proper QA will result in a weak end product. If the quality standards drop, the project will experience negative consequences such as re-work, liability and reduced margins. The project management team needs to understand that the cost of preventing errors is lower than the cost of fixing them.

Not learning from past project management mistakes
In every completed project plan there is a wealth of intelligence that rarely gets mined. Why did our project ship date slip by a month? How comprehensive were our initial specifications? How accurate was our team at estimating their tasks? A key benefit of using a project management tool is the ability to access the data that can provide answers to these questions. If a team is committed to self-improvement, they'll reap significant rewards by spending a few hours conducting post-project analysis.

Project Management Success Tips

Project management is rarely straightforward. The wrong people are assigned to the project. People don't know what is expected of them or get conflicting information. The scope changes. Deadlines aren't met. Put more succinctly: Stuff happens. So what can businesses, and project managers, do to improve the odds of projects being completed on time and on budget? Dozens of project leaders and project management experts share nine secrets to successful project management.

Ensure that you have full project details before starting
Creating a completely detailed project scope approved by all stakeholders is a necessity.
The scope should include interim milestones, with deliverable dates and a budget worksheet that represents all time involved. If the initial project write-up has enough detail, the better you and your client will interact through its production. Change requests will happen on every project, but this allows you to manage the client when something is out of scope.

Have the right (and right-sized) project management team in place
In order for a project to be successful, you need to have the right project team in place, people whose skills and experience can benefit the project, from the project manager on down. It also helps to "limit the number of people involved". uses the 'pizza' team methodology based on the idea that a team shouldn't be larger than 6 to 10 people". A manager really can only handle so many direct reports without losing grasp on either the vision for the project, details of the work involved, and personalities and personal requirements of their organization and staff". Maximize effectiveness, limit the size of your project management teams and involve people whose skills match the project requirements.

Set expectations -- and milestones -- up front
Set relatively (based on risk) frequent milestones and check in often to ensure projects stay on track. If you only set longer-term or high-level milestones, you won't realize a project is in trouble until it's too late. Set multiple project benchmarks and iterative reviews to make sure the money being invested in an IT project is being used efficiently and that project goals are being addressed.

When [everyone] on the team clearly understands the [scope] from the beginning, you eliminate the ambiguity that can derail a project." Do It Wiser, hold a kickoff meeting, where everyone involved attends. Kickoff meetings "help to set expectations," where you can "discuss the project in detail," create a workable roadmap and assign people roles and responsibilities.

Be clear about who is responsible for what -- and deadlines
When multiple people are collaborating on the same task, assignments, deadlines and other important details often get lost in translation. To avoid confusion, "determine which team members are responsible for which pieces of work [up front], and enforce accountability. An online task management program is a simple way to do this.

It's important that each member of your team understands what is expected from them. This includes the full scope of the project and a precise timeline of when tasks need to be completed." Because every project is different, "it helps for all of the key players to have a solid understanding of how each of their efforts contributes to the project as a whole. Project milestones and benchmarks are great for managing these expectations and keeping teams on track with deadlines.

Don't micromanage
Meet regularly with the team members who will be working on the project. However, allow them breathing room to work without feeling micromanaged. Creating a balance here is key to ensuring that work is being done and that team members feel empowered to do their best work.

Make sure you have a good system in place for managing the project, one that everyone can and will use
Email seems the most obvious form of communication when managing a project, but it can hinder progress. Trawling through email threads for previous correspondence is a huge time waster. Using software that keeps all project information and communication in one place not only saves time, [it] maintains a productive work space.

Keep team members motivated by rewarding them when milestones are reached
It is useful to set milestones while planning projects. To ensure projects stay on track, "recognize team members whenever a milestone is met. Celebrating milestones can be a great way to track progress while keeping team members motivated.

Hold regular project status meetings or calls, but keep them short
Frequent communication with all members of the team as well as the client is the best way to ensure a project is on track."This is especially important in a virtual environment, where [you] don't have the luxury of popping into a colleague's office to check the status of a task. I find scheduling regular calls in addition to all the other forms of digital communication we use ensures open and clear communication for all concerned.

While keeping everyone up to date on the project's status is essential, you need a way to communicate everyone's status to the rest of the team without getting bogged down by the details. To avoid participants tuning out, "keep status meetings short and sweet [by limiting] everyone to [for example] 90 seconds of talking. This encourages team members to focus on the most relevant details about the past week."

Thursday, March 3, 2016

Project Statement of Work vs Business Case

The project statement of work (SOW) and the business case are inputs to developing the project charter, but each contains different information. 


The project statement of work (SOW) is a narrative description of products or services to be delivered by the project and is provided by the project initiator or customer for external projects or the sponsor or requesting organization for internal projects. If the project is being done for an external customer, the SOW may be received from the customer as part of a bid document.
The SOW details the business need for the project, the product scope description, the strategic plan, and the characteristics of the product the project will create.
Business Case
The business case will confirm the business need and drivers for the project and will most likely include information on a cost benefit analysis, so as to justify the funding of the project, such as: net present value (NPV), internal rate of return (IRR), and/or return on investment (ROI).
The business case should also reference the driver behind the project, such as: market demand, organizational need, customer request, technological advance, legal requirement, or social need.
Both the project SOW and the business case are critical inputs to the development of the project charter. The SOW is generated by the requesting party, detailing what they are requesting, whereas the business case is developed internally, usually by the project sponsor, to provide a financial and feasibility analysis of the project.

Project Management Metrics

Gauging whether there is incremental improvement and setting up mechanisms to track and measure these improvements is the difficult part and this is where Metrics come in.

Metric’ is defined as “Standard of measurement by which efficiency, progress, performance, productivity, quality of a deliverable, process, project or product can be assessed”.  Metrics help in building predictability, improving organization’s decision making ability, and lay out what is working and what is not working within the organization and help guide the management focus in the right directions.

Project management metrics enable Project managers to:

  • Assess status of ongoing project in terms of schedule, cost and profitability.
  • Foresee any potential risks.
  • Nail down the problems much before they become severe.
  • Keep a check on project profitability.
  • Assess productivity of team.
  • Assess quality of work products to be delivered.

There can be different project management metrics defined based on complexity and nature of project. However, following five performance metric groups cover all the important aspects of a project to measure during execution:

Metrics #1: Schedule and Effort/Cost Variance
The goal of this metric is to measure the performance as well as progress of the project against signed baselines.  This metric is very important and is the base for profitability of project. The EVM (Earned Value Management) concept, as defined by PMI standard PMBOK, is the commonly used method to track this metric. It integrates project scope, cost and schedule measures to help the PM to assess and measure project performance and progress. The principles of EVM can be applied to all projects, in any industry. Under this method, at any given point in time, project performance to date is used to extrapolate the expected costs and duration at project completion. This technique uses past performance (i.e. actuals) to more accurately forecast future performance. EVM develops and monitors three key dimensions of each work package:
Planned Value (PV)How much you planned to spend for the work you planned to do i.e. it is the authorized budget assigned to the work to be accomplished for an activity or work breakdown structure component. Total PV is also known as Budget at Completion (BAC). PV at any stage = (Planned % Complete) X (BAC)
Earned Value (EV)Earned value is the value of work performed expressed in terms of the approved budget assigned to that work for an activity or work breakdown structure component. It is the authorized work that has been completed, against the authorized budget for such completed work i.e. EV is ‘how much you planned to spend for the work you actually did’. Earned Value is also known as the Budgeted Cost of Work Performed (BCWP).
Actual cost (AC): Actual cost is the total cost actually incurred and recorded in accomplishing work performed for an activity or work breakdown structure component. It is the total cost incurred in accomplishing the work that the EV measured. I.e. how much you spent for the work you actually did. Actual Cost is also known as the Actual Cost of Work Performed (ACWP).
Using these three variables project Schedule variance and Cost variance metrics can be derived which shows if the project is running over or under budget; project is running behind or ahead of schedule, as follows:
Schedule Variance (SV) is the measure of schedule performance of the project. It is the difference of Earned value and the planned value i.e.  SV = EV – PV
  • Positive result means that you are ahead of schedule.
  • Negative result means that you are behind schedule.
Cost Variance (CV) is the measure of cost performance on the project. It is equal to earned value (EV) minus actual costs (AC). Any negative CV is often non-recoverable to the project.
CV = EV – AC

  • Positive result means that you are under budget.
  • Negative result means that you are over budget.
Since EVM method allows PM to extrapolate the expected costs and duration at project completion based on project performance to date, PM can develop a forecast for the estimate at completion (EAC) which may differ from the budget at completion (BAC) based on project performance. Forecasting of EAC involves making estimates or prediction of conditions and events in the project’s future based on information and knowledge available at the time of forecasting. EAC is typically based on actual cost (AC) incurred for work completed, plus an estimate to complete (ETC) the remaining work. I.e. EAC = AC + ETC.
Based on this PM can also derive another metric, Variance at completion (VAC) = BAC – EAC

Metrics #2 – Productivity: Resource Utilization

The objective of this metric is to measure productivity of resources involved in project and let PM assess over or under-utilization cases.
Utilization% = Total Effort spent by resource/Total Budgeted Effort for the resource
Budgeted effort is the planned billable work of resource. Any over-utilization and under-utilization indicated by this metric has an impact on the project’s profitability. It is important for the PM to track this metric very closely and find out the reason for deviations and the action items to bring back resource utilization to optimal level. Delayed projects, increased ramp up activities, less work provided by customer, unplanned vacations, less competent resources can impact this metric. To get better control over this metric, robust time reporting systems should be available in the organization. Using this, PM can analyze effort distribution across different project phases/activities. For e.g. Effort distribution can tell PM that how much effort is being spent on defect resolution, customer support or design activities. PM can take corrective actions based on this, if required. For instance, if the resource is complaining that customer support is taking considerable time but the effort distribution shows it otherwise, PM can see where the corrections are needed on what resource is doing. Effort distribution from time reporting systems can also tell the areas of improvement for  better estimations/planning for the next project.

Metrics #3: Change requests to Scope of work

Signed Scope baseline with customer forms the baseline for the entire project planning and development. Any change to signed scope should happen in controlled manner. So here comes another important metric for PM to track i.e. the number of change requests coming from customer for the already signed scope of work. Each and every change request, once approved by internal change control board (CCB), requires update to Scope baseline which in turn has a cascade impact on cost baselines and schedule baselines and resource plans. Uncontrolled change requests often result in project scope creep and further impact negatively on the project cost/schedule, which is the worst thing to happen for any project. PM should never allow such scope creep. Based on the magnitude of the variance from original scope baseline, CCB should decide whether to accept or reject the change request and this decision should be communicated back to customer. In case of acceptance of change request, the impact on project cost and schedule should be clearly communicated in written form to customer and a written agreement from customer secured on those from customer before proceeding.

Metrics #4: Quality and Customer Satisfaction

Throughout the execution of project, Quality Assurance should always be on the radar of project manager. Quality is defined as the number of severe, medium or low defects delivered through the lifetime of the project. It indicates the health of the deliverable to the end user and drives the Customer Satisfaction. PM needs to define, based on project type, what severe, low and medium means. Quality should be reported throughout the life of the project; the later defects are caught, the more impact they will have on the project. Under quality metrics, following are the key ones to track:
Defect density = Total number of defects found/ Measure of size.
For e.g. in case of software projects this can be: how many defects are found in 1KLOC (Kilo line of code). In general, size measure can be considered as planned effort like ‘person day total planned effort’.
Defect age
Number of days since the defect is open and not fixed. It can also be inferred as the time customer has been waiting for their issues to get resolved,
Defect resolution rate = Total number of defects resolved/ Total effort spent
Rate of closing the open defects over a period of time. If the rate of resolution is not in line with the defects being opened over a particular time, this indicates to the PM a situation of concern.

Metrics #5: Gross Margin

Gross Margin is the mother of all metrics and the quickest way to determine if your business in on track or not and acts as an early warning system to put in place margin improvement initiatives. Ultimate goal of project execution is to bring revenue to organization with the approved gross margin. Gross margin (GM) is basically the difference of total revenue and the total cost spent on project i.e. profit.

When a project is started, certain GM levels for the project are approved by project sponsor. This approved GM value is generally based on project scope definition, duration, a forecast of resources: onsite, offshore and organization’s investment analysis. Project PNL (Profit and Loss) statement gives a way to PM for tracking his/her projects GM metric at any point of time. For this, PNL statements and forecasts should be current documents i.e. changes in project parameters need to be reflected quickly in this statement to keep the PM informed about any potential risks to project profitability. All the above four project management performance metrics impact this metric, if not handled in controlled manner. A good organizational level PNL tool rather than manual excel sheets reduces the overhead on PM here.