Abstract
One of the most tedious tasks for a project manager is updating and maintaining the project budget and schedule. These documents are very dynamic – changing constantly with accrued expenses, missed or accelerated milestones, and project scope changes. Maintaining an accurate pulse on a project involves significant time and effort on the part of the project manager. And time is a precious commodity that can be spent in many other ways. Doing without a project schedule or budget is unthinkable – yet many project managers skimp on these essential project controls elements due to time versus perceived value. How then, do you make the most of the time you have, and accurately track project status without becoming a slave to the statusing process? There are alternatives, and there are some no-nonsense tips that can help project managers in this quest to balance the job demands.
This presentation will look at project control functions from the reporting process backwards -- providing several alternate approaches to establishing the right level of detail, the right amount of effort, and the right attention level to the project tracking processes.
Introduction
Project managers face numerous challenges in today’s information age. With the rising recognition that effective project management can produce numerous dividends in controlling costs and bringing new products and services into the marketplace faster, while still maintaining or even increasing innovation in organizations, it’s no wonder that everyone seems to want to know everything about what’s going on in the projects occurring within the organization. Add to that information technology systems that are capable of tracking metrics on just about everything under the sun, and a project manager can easily feel a sense of data overload. So, how do we as project managers balance the effort required for analyzing and reporting status data, the cut-and-dry duties, while still working on managing and communicating to stakeholders about the project, the softer side to the job?
Background
Project management is both a science and an art (Crawford, 2002, p. 2). Project controls, on the other hand, are almost entirely a science. Project control efforts are typically data, time reporting, and tracking intensive. Project control work can be considered the accounting part of project management, though there are some facilitation aspects to it as well. Project control products provide the baseline for project efforts, how changes are handled and communicated, and show where and how a project is progressing based on cost, time, and scope.
As a project manager, understanding expectations of key stakeholders is a critical part of achieving overall success. This is more representative of the art side of project management, where there exists subtleties in dealing with different groups of people. Knowing what your project stakeholders expect in the way of information related to project control is one element of this softer side of project management. Then, managing to this expectation and standardizing towards a common reporting mechanism can be achieved.
Who Needs What Information?
The Essentials
All stakeholders in the project require some information regarding the project’s status. However, the level of information varies accordingly with the role of the stakeholder. While the project manager requires information to the highest level of detail and fidelity possible for the project, the same level of detail can overwhelm or confuse a project sponsor. Likewise resource managers need a good assessment of short-term and future needs, while project team members just simply require notice of the next task at hand. Furthermore, project stakeholders have differing expectations for levels of project control information, and managing such expectations can be a challenge in itself.
It can be difficult to manage such project control information requirements, especially in a real-time changing dynamic environment. Furthermore, information reporting requirements can also vary according to the project’s size, level of risk, as well as other variables. Nonetheless, a fundamental aspect to project controls is the recognition of such differences in reporting needs relative to the roles and responsibilities for each of the project team members.
One Dataset
In order to assure commonality, maximize efficiency and minimize confusion, it is essential that the project’s stakeholders are all working from the same data system that holds project information. So what does this mean? It is essentially stating that we need to compare apples to apples in terms of data for project control information. Executives cannot be looking at cost status reports that are derived from one accounting system while the project managers are operating off of another. Every party must be looking at data that comes from a single common repository, meaning that data formats, definitions, and terminology are consistent.
By using a single dataset, communication efforts within the project can focus on stakeholder needs rather than on interpreting data. The common project data structure serves as the common language for the project. Then, executives and project managers can focus on communicating to each other about key project events, functional managers can focus on balancing their resources to support projects, and the burden on project managers to understand and interpret data from multiple systems is eliminated. This leads to a much more open, collaborative environment where the likelihood of success is increased.
Maturity and Reporting Requirements
So we have many parties that need project status information, and this information is important to all of them for different reasons, and they all need different levels of information. Sounds like it’s impossible to handle and balance right? While this may seem daunting, some organizations already do much of this. In fact, the more mature an organization’s project management processes, the more mature its project controls plan (Crawford, 2006, pp 6-9).
A challenge to implementing a project controls plan is assessing what level of reporting is needed for a particular project. Not all projects require the same level of controls. The level of detail and frequency required for a project status report can vary according to various factors. Project size, risk, client requirements and other constraints can dictate a higher or lower level of fidelity for project status reports. A summary of overall costs incurred, performance status and schedule status monthly may be sufficient for one project, whereas for another, it may be necessary to provide such a report weekly.
It is important to reconcile and acknowledge what levels of reporting are expected for a particular project early on in the project life cycle. Shortly after obtaining agreement on a project’s charter, most project managers go forward with producing the WBS and schedule for the project, which are the plans for the work to be done on the project and the deadlines associated with milestones on the project. Why not also have plans for status communications, like what type of status information is to be given to whom at what time? The levels of communication expected and planned should be addressed in the project’s Communication Plan document. This plan, often in the form of a matrix or table, establishes the formal project status control reporting, assuring that the correct parties get the information they want/need in the right time to the right level of detail. This plan, once agreed on by all the project stakeholders, can eliminate duplication of effort and rework in project control activities, and also achieve greater synergies within the project team. By having an agreed upon plan for what types project information should be communicated when, via what medium, and the reason for such communication, the expectations of project stakeholders for project status information can be managed more effectively.
Project Characteristics and Their Impact on Reporting
The level of controls necessary on projects can vary greatly according to a number of factors. Clearly, project size, complexity, risk, and importance are all factors in determining the thoroughness in project documentation and level of tracking and control required. Consideration of these factors along with organizational standards (if they exist) should dictate the amount of effort placed on performing project control functions. The table below gives some general guidelines and considerations one must take into account when establishing their project control reporting plan.
The factors listed above are representative of what can impact most projects, but the list is not necessarily all-inclusive. In fact, the level of controls needed for any one project is highly unique to both the project itself and the organization conducting the implementation of the project. Again, the level of project management maturity of the organization plays a role in what efforts are conducted in the project controls realm, but only along with taking into account other considerations. Overall, the amount of project controls required depends on some summation of all such factors, so that the impact of the project can be assessed. The impact of the project really determines what degree of reporting is required.
Do You Classify Projects?
When looking at a portfolio of projects, all with varying levels of impact according to the various projects characteristic assessment factors, one might want to separate projects according to their impact level. By separating the high-impact projects from the low-impact from the medium-impact, one may implement similar project control plans for similar projects, thereby promoting the use of established processes for project control and reporting.
For instance, the high-impact projects are those considered to be more risky, complex, visible, etc. As such, then one should really make sure that good metrics are kept on these projects so that any changes impacting the project’s schedule, scope, or cost can be addressed quickly and effectively. Extensive analysis of earned value data should be conducted. By having a comprehensive project controls plan, risk can be managed at the appropriate points early on in the project, thereby minimizing associated costs with those risks.
While a thorough project control plan as described above works well for an organization’s high-impact projects, it’s probably overkill for the low-impact ones. On the same token, the correct project controls plan for medium-impact projects is probably somewhere in-between what’s required for low-impact projects and high-impact ones. However, by grouping the projects of similar impact together, one may establish a consistent project control plan for all of those projects. To encourage the use of organization-wide standards, project managers can even re-use control plan documents (and modify them for their specific projects) such as the project Communication Plan for projects of similar impact. This reduces the workload on the project managers and assures consistency for the organization’s project controls implementation.
At a minimum, the project controls plan should include a WBS, schedule, Communication Plan, and status reports containing information on the project’s milestone progress and cost status. However, the degree of information and frequency for which these reports are distributed depends on both the audience for the report and the project itself.
Frequency of Reporting
The frequency of reporting required is dictated by the impact assessment for the project. Higher impact projects, due to their higher risk, size, complexity and importance, will necessitate a more thorough project control plan. An example of a high-impact project might be the construction of a new hospital, where there are large costs, new technologies, and higher risks associated with such a project; you don’t often build new hospitals and you don’t really know what might happen. Coincidently, these high-impact projects pose the greatest challenges to the project manager in terms of managing the workload required. Reporting status weekly, daily, or even hourly is not unheard of for these key projects. Again, a clearly established Communication Plan can prove to be most effective in these cases, where stakeholders can provide their perspective as to the frequency they are expecting to hear status and the project manager can assure that such status reports are provided to the appropriate parties.
If a project is of lower impact, less frequent reporting is usually sufficient. For instance, if an organization is implementing a project to install an update package of software, and it just completed a similar project last month, and it is using established software and test runs, and the project is of minimal cost, with virtually no visibility to upper management, then it makes little sense to conduct an extensive tracking and reporting program. The project is of low impact and less project control is needed, perhaps a status report monthly is adequate. However, in order to properly manage reporting expectations again, what is to be reported and the frequency of such status reports still needs to be documented and shared to project stakeholders in the project’s Communication Plan.
Can You Do It Alone?
What Work Can be Delegated Effectively, and to Whom
As project managers, we tend to have a tendency to think that we need to perform all project-related central functions. This would include meeting with the project sponsors, executives, clients, functional managers, orchestrating project events, planning for the next phases of the project, managing changes, etc. The list of project duties goes on and on, and we think of the project control function as inherently part of the project manager’s duties too. This work, while important and essential for project success, is often mundane and requires lots of effort. We tend to think of project controls as just part of the job of a project manager, but there are so many more things that a project manager must do too, and the other duties are potentially (and often politically) more important than the statusing process.
Fortunately, help is available to project managers. With the advent of enterprise-level software management systems and an increased focus on training and advancing organizational project management maturity, there are several options to free project managers from the project controls function. The project manager no longer has to be the hub of all status information; he or she can pull data from the same data system as other project members. Additionally, the project controls function no longer has to be under the reign of the project manager, it can be done externally, either delegated to a dedicated project planner or even done remotely by a remote project controls office, which performs the project status function for all projects going on in the organization, as part of the PMO.
Project Planners and Controllers
Project planners and project controllers are people dedicated to monitoring a project’s status. The same person can perform both the duties of the planner and the controller. Project planners and controllers, when assigned to a Project Office, have the following responsibilities: (Crawford, 2002, p. 96)
- Schedule Development
- Resource Forecasting
- Critical Path Diagramming
- Project Budgeting
- Planning Support
- Cost Estimating
- Software Tools Support
- Project Prioritization
- Tools Integration
- Variance Analysis
- Project Integration
- Resource Forecasting & Integration
- Reporting
- Project & Program Reporting
Note that the duties of project controls as listed do not take away from anything that a project manager is needed for. The project planner/controller is operating in the science realm of project management and directly supports the project manager. The planner/controller is establishing, maintaining, and using the enterprise-wide systems that keep data on projects. He or she is producing the status reports in the correct level of detail needed for various stakeholders in the project, calculating variances, and looking for opportunities to reprioritize as necessary. It is absolutely essential that the planner/controller keep in constant, consistent communication with the project manager, as it is critical for the project manager to be as up-to-date with all project information as possible. However, the key benefit of adding a project planner/controller position external to the project manager is that it frees up the project manager from the reporting process, allowing him or her to focus energies on duties that cannot be delegated, such as face to face communications and stakeholder management
PMO Help
For organizations that have a multitude of projects that all require different levels of reporting, the project controls functions may be too much for even an additional project planner/controller to handle. Another way that some organizations may assure that they can have on-demand status of their projects is by establishing a project controls center, which sits under the PMO. The project controls center, which is separate from the project manager, maintains the project status software control and provides the reports necessary to various parties for the enterprise. For larger, mature organizations, this is often used, but not necessarily so labeled. It is common for PMO’s to maintain enterprise level data, and distribute this information to the various groups of users they support.
Bringing It All Together Easily
Perspective
Any project manager knows that the success of a project is dependent on properly implementing, controlling and completing the project at hand. Sounds simple enough? It is. Unfortunately, project managers are now saddled with a tremendous amount of tasks that they must do in order to accomplish those simple duties. From dealing with task team members to clients to managers to suppliers to executives, who has time to look at time and cost accounting for project status? But project control is one of the most essential parts of managing a project effectively. So, we’re left in a bit of a quandary, where we as project managers have to be miracle workers and accomplish more with less time.
In some cases, the organization in which the project manager operates in is simply not mature enough in its project management processes to decouple the project controls function from the project manager. In these cases, the organization needs to first establish some sort of standards for reporting and maintaining project status data so that at least these processes can be repeated from project to project first. Until the processes are at least repeatable (a Level 2 according to the Project Management Maturity Model (Crawford, 2006, p. 7)), it is of little use to delegate project control duties from the project manager to others.
Nonetheless, it now makes sense in most organizations with established processes to consider other options for project control. The function no longer has to be done by the project manager and with the tools now available for tracking and keeping project data, reporting doesn’t even have to be done in the same location as the project manager. Project control can be performed by a project planner/controller or a project control office remote from the project manager. As long as the project manager keeps in consistent communication with his or her control office, he or she can feel confident about maintaining the status of their project.
Conclusion
Project management, it is said, is an art and a science. Our goal with simplifying things for the project manager is to understand what part of what a project manager does is considered the science, train others to help the project manager perform the duties of the project management science, and leave the project manager to focus on the art of project management.
Ultimately, the feedback and results from project control efforts falls back onto the project manager. However, that doesn’t mean the project manager is alone. He or she can reach for support from a project planner/controller, or a PMO (and these resources do not necessarily need to be full time employees). This support, while focused on the science of project management and project control, helps the project manager as he or she communicates (via whatever medium established) to the project stakeholders. This is where science meets art, and the end goal of all this is to make informed project and ultimately business decisions, and have the science support the art. Together, the project organization can best meet the objectives of the project and the reporting needs of its stakeholders.
Crawford, J. K., (2006). Project Management Maturity Model 2nd Edition. New York: Auerbach Publications.
Crawford, J. K., (2002). The Strategic Project Office. New York: Marcel Dekker.