Project Cost Recording and Reporting

Alexia Nalewaik

• Publisher: Routledge
• Year: 2019
• Print ISBN: 9781409450993
• eBook ISBN: 9781000758030
• Topic: Business
• Subtopic: Business General
• Index: Business

Communication is a vital part of project management, and reports are one of the preferred vehicles for transmitting information to an intended internal or external audience. Reports are also part of the system of control and governance on projects, used to bring attention to issues and prompt action to improve project outcomes.

There are countless ways of combining project information for consumption by stakeholders. This book discusses the purpose of project reports, and provides examples of the format, content, timing, and audience for various types. Using principles of stakeholders and risk management, it presents a rationale for communication plans, enabling appropriate reporting at the project, program, and portfolio level. The author also:

• Presents tangible experience and suggestions for developing project reports.
• Discusses project reports in context, as applicable to types of stakeholders and the project lifecycle.
• Identifies sources and types of data required for adequate reporting.
• Offers examples of report formats, graphics, and content.
• Reflects on typical challenges encountered with project reporting.

It is essential reading for practitioners and students of project management, cost control, and accountancy.

1 Introduction

 

The world is complicated, and messy, with lots of moving pieces. This is true both on a grand scale (the universe, the earth), and on smaller scales (daily life, countries, industries, projects). One way to make sense of the world and its many pieces is by categorizing elements, putting related parts together in such a way that they comprise a whole but can also be analyzed in smaller, more manageable portions. Processes that can be measured and understood can then be controlled. That whole and its parts may be quantified, or may be merely described, or may be analyzed using a mix of the two approaches. The output of such analysis for business purposes is usually a report, a graphic and narrative creation that takes the many (sometimes seemingly disparate) fragments of data and simplifies them into a comprehensible snapshot.

The primary function of reporting is communication. Reports are used to inform stakeholders of status, disseminate information, provide data and news for assimilation and decision-making, and elevate the visibility of problems and opportunities. Reporting also cultivates trust by enabling transparency, encouraging accountability, and celebrating success. The report itself is naturally less important than the decisions that form project outcomes, but it is undoubtedly an indispensable vehicle for such decision-making and contributes to the project permanent record.

There are many different formats for reports, and countless ways of combining information. How does the project team decide which format to use, and what information to include? In the sphere of projects, they make that choice by looking to the project stakeholders. Stakeholders are impacted by projects (and vice versa), but they might not necessarily be an active part of the project universe. As such, they often rely heavily on reporting from the project team in order to make decisions. A tendency to overgeneralize project reports may fool stakeholders into believing they fully comprehend the project status quo. Different stakeholders have different information needs, perspectives, and objectives, and thus they have different expectations of reports, while at the same time wanting the unadulterated facts.

The purpose of this book is to discuss the content and format of project reports, and provide guidelines in the context of available technology, stakeholder and management needs, and obstacles to reporting. The book opens by describing the need for project reports, the stakeholders for which they are produced, and situations in which they may be contractually required. Data, data sources, and data management infrastructure are discussed next, in the context of the project lifecycle. The reader is then engaged with a more in-depth discourse about different types of reports and graphics used in projects, including their audience and timing, with examples, explaining specifically why the report types differ and how they are used. Specifically excluded are typical governance documents used to manage the project on a daily basis, such as checklists, meeting minutes, and forms. The author describes some challenges experienced with project reporting, offering advice on how to avoid some of those challenges and how to approach special-purpose reports. The book concludes with some thoughts on the future of project reporting.

2 Stakeholders

Just as beauty is said to be in the eye of the beholder, the same is true for success. Different stakeholders have different definitions of success. Because stakeholders each have their own motives and perspectives, these definitions of success can be widely divergent, such that a project can conceivably be considered both a success and a failure at the same time. It seems impossible, even ridiculous, but it is true. While cost, schedule, and quality are common measures of success for projects, some stakeholders may judge the success of a project by other measures, such as degree of acceptance, level of prestige, the way the project reflects on them, and much more. Understanding stakeholders is, thus, the key to benefits realization. Chapter 2 – Stakeholders, describes some categories of people who define and can directly or indirectly influence project success.

Assurance

Simply put, decision-making requires information. That information includes data that is correct, timely, complete, unbiased, and reliable. The data can be assembled in seemingly endless combinations, yet must be presented in a usable format for a particular purpose. Reports should be tailored to their intended audience, so as to be concise, comprehensible, consistent, and provide the information needed for stakeholders to stay informed, make decisions, and take action. However, the reporting function must also be dynamic, able to respond to changing project conditions. Decision-making in projects requires accurate, timely, and relevant status reporting, yet all too often reports do not serve their intended purpose. Stakeholders seek the information they need, with a caveat: they also want assurance.

There are several applications of “assurance” as a noun; two of them apply here.¹ One is a state of certainty or confidence in something. The other is a statement intended to provide such confidence. Stakeholders wish to have confidence that the information they receive is accurate and appropriate for their purposes; both internal team members and external consultants provide stakeholders with those assurances. The concept of assurance is closely tied to that of accountability, whereby the project team or consultants providing the data are responsible for the quality, accuracy, appropriateness, and timeliness of the information provided. The importance of such accountability cannot be overstated, as errors need to be corrected immediately lest major decisions be based on the incorrect information and advice given.

Assurance and accountability both assume reporting is unbiased and objective, conditions which (sadly) might not always be true if the report comes from within the project management office (PMO). Independence of external consultants suggests disassociation from the situation and immunity to influence, whereas project team members are often deeply embedded in the culture of the project organization and the tangled relationships therein. Then again, external consultants might not have access to all available data and discussions, and thus might not understand the full picture. If employed as consultants internal to the team, project team members may have dual loyalties – to their employer and to the external client. Such circumstances may make certain responsibilities difficult, such as: critical questioning, impartial status assessment, and delivery of bad news.

Optimism and cognitive delusion are common occurrences when reporting project status; failures tend to be downplayed, and results spun into hopeful forecasts. Delayed reporting of data may result from internal sensitivity, pressure, or politics. All these acts of self-protection can result in an overly positive representation of project performance, blurring risks and change, which then obstructs early action to remedy identified issues.

Stakeholder categories

Before discussing stakeholder expectations, the project team first needs to identify and understand who the project stakeholders are, how much they can impact the project, and how they judge project success. Stakeholders may be individuals, formal groups, and entities such as companies and governments. They each have different levels of motivation, interest, power, and influence, which may change throughout the project.

Responsibilities to project stakeholders may fall into several categories:²

• Fiduciary duty

• Decision-making (corporate governance)

• Participation

• Fairness

• Cooperation

• Accountability

• Strategic management

• Legitimization

• Risk management (deflecting criticism)

• Social construction (image)

The number of project stakeholders can be considerable, and failure to address their needs may mean failure of the project. Their connection to the project may be contractual, societal, financial, familial, political, emotional, and more. They may be internal or external to the project, explicit or implicit, and involved at any or every phase of the project lifecycle. The stakeholders list may include: companies, corporate employees, contractors, suppliers, consultants, neighbors, investors, partners, end-users, the media, public officials, public or private agencies, the general public, special interest groups, and even past and future generations.

The mindmap below illustrates just some of the categories of stakeholders that can be found on a project.

For the purposes of reporting, identifying stakeholders also means knowing their role on and connection to the project. From there, their level of involvement, primary concerns, definition of success, language and terminology, and level of tolerance for risk and change can be used to customize and shape reports for them. Stakeholder identification should be revisited periodically during a project, because stakeholders often depart in the middle of the project and new stakeholders arrive.

Communication with stakeholders is one mechanism for establishing and managing their expectations. The recommended stakeholder audience for specific types of reports is provided later in this book.

Internal stakeholders

Governing boards

Some formal oversight bodies on a project and within an organization are stakeholders that serve as a governance mechanism. Examples of these are: board of directors, steering committee, citizen oversight committee, governance, project sponsor, project executive, and audit committee. These groups may enact corporate, legislative, or regulatory-required guardianship of the project, monitoring project progress and providing guidance to project management and leadership. Each has an agreed-upon high level of authority, area of responsibility, and organizational charter. Members of such oversight bodies need to understand the strategic implications, risk, and potential outcomes of project actions; without adequate reporting, they may make decisions based on out-of-context information. The project team may need approvals from governing boards for certain project actions, especially budget approval and changes in goals or scope. A governing board may use its influence and authority to assist the project, solve problems, and resolve issues. Governing boards often serve as an intermediary for reporting to organizational executive officers such as the Chief Executive Officer (CEO), Chief Information Officer (CIO), Chief of Operations (COO), Chief Financial Officer (CFO), and external authorities.

Figure 2.1 Stakeholder mindmap.

Source: Nalewaik, Alexia and Mills, Anthony (2016). Project Performance Review: Capturing the Value of Audit, Oversight, and Compliance for Project Success, p. 52. London: Routledge.

Project or program sponsor

The sponsor is the ultimate executive on the project or program team, a member of the client organization external to the project or program. They approve major project or program activities, changes, and expenditures, monitor the effectiveness of project or program management, and are tasked with both project visioning and removing roadblocks to project or program success. They have authority to direct all staff, secure resources, resolve conflicts, and have sufficient influence to engage with key stakeholders. They may chair the steering committee or other governing boards. The project or program sponsor may serve as an intermediary both within the organization and with external stakeholders.

Chief financial officer (CFO)

The chief financial officer exists at a corporate executive level, often removed from projects yet connected via the monitoring and provision of project financing and governance. The language they use is very specific, and must be understood by the project team. Return on investment (ROI), depreciation of assets, taxation, the time value of money, revenue, color of money (use of funds received from different sources), and expenditures are terminology they use. In the finance office, success of a project may be defined purely on financial metrics. The project ...

Table of contents

• Cover
• Half Title
• Title Page
• Copyright Page
• Table of Contents
• List of figures
• Foreword
• Acknowledgments
• Acronyms and abbreviations
• 1 Introduction
• 2 Stakeholders
• 3 Data
• 4 The reporting process
• 5 Types of reports
• 6 Challenges
• 7 Summary
• Additional resources
• Index