Introduction
The theme of this paper, unlike the famous story of mice and disappearing cheese that inspired its title, is not about managing change but rather about tracking changes affecting project plans and their impact on project performance.
Planning is critical to good project execution. However, planning alone is not sufficient. Projects are subject to numerous interferences that tend to stir them away from their plan. In order to ensure the success of a project, it is vital to know at any given time what the actual project performance is in terms of scope, schedule, quality, and cost. This information can then be analyzed and used to make informed decisions that will bring the project back on track.
The ability to obtain timely, accurate, relevant, and reliable project information is a challenge that all project stakeholders face. Software packages and techniques have been developed to assist in this regard, but they are often complicated and require extensive training, too expensive, and not everyone can afford them or they are of limited use considering the project management maturity of the organization. When faced with a program or portfolio of projects, data quantity becomes an additional concern.
A streamlined approach has been devised and implemented that simplifies the reporting of project information while still offering adequate project performance monitoring capabilities. The method relies on a simple concept and a set of special reporting rules. Implementation considerations, as well as other potential use of the method, are covered in the following.
The Information Challenge
Vision (audacious goal)
In order to better highlight the information challenges, let's first establish what a perfect world would look like through the following Vision Statement:
The management of all projects will comply with the processes, tools and techniques established by the Project Management Institute (PMI®) as contained in A Guide to the Project Management Body of Knowledge (PMBOK® Guide) specifically, as it relates to the following key elements of planning and control:
- A work breakdown structure (WBS) exists that accurately describes the project scope;
- Duration and effort estimates are prepared for all tasks;
- Resources, out of a central managed pool, are assigned to each tasks;
- All tasks are linked to a predecessor and a successor;
- The schedule has been baselined;
- All costs information have been uploaded with their corresponding tasks;
- Earned Value Analysis (EVA) is used to measure project performance;
- Project schedules are regularly updated to reflect changes occurring during execution;
- Schedules are all available in one central location;
- Staff is knowledgeable about project management tools and processes.
All project management practitioners should acknowledge the idealistic nature of the above Vision. While some practitioners, probably few, may recognize their current project management practices, most would consider this a long term goal, if at all. This difference between reality and envisioned future highlights the two components of the information challenge: data and data collection.
Data
Not all data are created equal. In order to fully serve their purpose, project performance data must meet certain criteria that fall into the following four categories: time, quality, quantity and cost.
Time
- Freshness: the data must be recent enough to still be relevant.
- Update frequency: the data must be updated at regular, known, intervals.
Quality
- Relevance: the data must be able to serve the purpose for which they are being gathered .
- Complexity: some data, such as resulting from EVA, may require special skills not necessarily mastered by all staff collecting and/or using the data.
- Consistency: the nature and type of data must remain the same over time in order to be comparable.
- Standardization: the same data is collected in the same manner on all projects, all the time.
- Additional use: some data can be used for multiple purposes.
- Consolidation: some data can be representative of large portion of project activities.
- Accessibility: the data must be easily available to and usable by those who need them.
- Auditability: the data must be verifiable and backed up by evidence.
Quantity
- Completeness: there must be enough data for the information to be relevant.
- Limitation: too much data prevents visibility and leads to information overload.
Cost
- Effort: the cost of data collection should not outweigh the benefits of information availability.
- Tool: the cost to acquire, operate and maintain any tool (see below) must be justified by the anticipated benefits of information availability.
Failure to take the above criteria into consideration could negatively impact the effectiveness and efficiency of the project performance monitoring effort and reduce the ability to properly react to project issues as they arise.
Data Collection
The data collection activity presents challenges in terms of tools used to collect the data, as well as project management maturity of the organization involved in the effort.
Tools
The Project Management industry has seen the emergence of a wide range of tools to help manage projects and track them. These software packages can be characterized as follows:
- Scope: from individual project to enterprise project portfolio.
- Complexity: a higher number of functionalities will lead to a more complex tool.
- Implementation: from individual licenses on staff PCs to a dedicated software server with associated database interfaced with an existing ERP system.
- Training: from a few hours to one week.
- Operation: from built-in help files to dedicated resources.
- Cost: proportional to scope, complexity as well as implementation and operation considerations.
Project management software is meant to assist project stakeholders in their involvement with the project. Some implementations have led to use of the tool as an end in itself. Additionally, full benefits of the tools are usually achieved through the full deployment of functionalities; this does not always happen. Numerous examples exist of failed implementations or instances of complex tools turned into glorified time reporting systems. As highlighted herewith, serious consideration must be given when selecting and acquiring such software.
Project Management Maturity
Ambitious efforts to comply with PMBOK® Guide or to implement a tool very often ignore the current project management maturity of the organization and people that are supposed to perform the tasks at stake. In many cases, engineers or developers are expected to perform in a project management capacity without any training or prior experience. In such an environment, no process or tool can miraculously instill project management skills by pushing a button! Team members cannot be expected to proficiently use tools, such as scheduling software, without any knowledge of WBS or other scheduling techniques. In order to be successful, data collection and project performance monitoring requirements will need to be tailored to the skills of the population at stake.
The Solution
Concept
A profound dislike for status report preparation combined with all of the challenges and constraints identified above as well as the need to track 60 projects on a yearly basis have led the author to devise a simpler method for project performance monitoring.
The concept relies on the assumption that a Project Life Cycle exists to which all projects must adhere. With the advent of quality management systems (ISO 9000), continuous improvement (Six Sigma) and other regulatory compliance schemes (e.g., Sarbanes-Oxley regulation), this should actually be a fact in most organizations.
The Project Life Cycle is broken down into phases separated by stage gates. Each phase consists of a series of activities or tasks that produce specified deliverables. Some of these activities and deliverables are critical to the project execution while other have more of a supporting or controlling role. These critical or key tasks and deliverables can then be considered representatives of the phase to which they belong.
Example: the production of detailed mechanical drawings for a construction project or of a Detailed Design Specifications (DDS) document for an IT project constitutes key tasks representative of the Design Phase of the respective Project Life Cycle of these hypothetical projects. The final approval or sign-off of these same documents constitutes key deliverables.
A high level modeling of the Project Life Cycle can then be accomplished by identifying, for each phase, the key activities and deliverables, therefore creating a simplified representation of the project or Project Model. This simplified representation should correspond closely to the high level WBS of the project.
Project performance monitoring can then be reduced to the tacking of the key tasks and deliverables of the established Project Model. Most interferences to the project plan should affect one of more of the key tasks or deliverables and therefore be easily identified and managed.
It is important to note that the above concept is not meant to replace the use of project schedules. It is supposed to supplement it with the intent to facilitate project communication and performance reporting.
Reporting Rules
To further streamline the approach and facilitate the performance reporting process, four specific Reporting Rules have been developed to be used in conjunction with the concept presented.
1. Limited Reporting
Reporting will be limited to the following information:
- Key tasks: start date, end date, percentage of work complete;
- Key deliverables: end date, completion status indicator.
2. Variance Reporting
Reporting needs to take place only when a variance from the baseline (initially entered dates) has occurred. If there is no variance, no reporting is needed and the data posted are assumed to be correct.
3. “Real Time” Data
Instead of generating reports at a given frequency (weekly for instance), therefore running the risk that someone may rely on data that may be outdated (in-between reporting cycles), updates must take place whenever change occurs, and as often as required. Some guidelines such as “no later than close of business” or “within 24 hours” may be instituted to help compliance with this rule.
4. Dynamic Tracking
The reporting of the start and end dates for the key tasks evolves along with the project. All future dates should be entered as “planned dates” and all past dates should be modified to “actual dates”. This way, a look at the project will provide immediate information as to the status of project activities (planned and actual).
Simplified Schedule Index
In an attempt to leverage existing project management techniques while maintaining the simplicity and ease of use of the method, a schedule performance indicator has been developed, the Simplified Schedule Index (SSI). The SSI is calculated for each (key) task of the Project Model.
The SSI is calculated as follows:
The SSI basically compares how much work has been accomplished considering how much of the time allocated to the (key) task in question has gone by.
SSI > 100% indicates task progressing ahead of schedule
SSI = 100% indicates task on schedule
SSI < 100% indicates task behind schedule
In order to maintain its simplicity, the SSI assumes linear progression of all data used, which is very often not the case. Unlike the Schedule Performance Index (SPI) in the EVA method, calculated for the whole project, the SSI is calculated at the task level. This should provide an acceptable approximation of the schedule performance trend for each of the tasks considered.
Benefits
The system described herewith (Project Model, Reporting Rules and SSI) offers numerous benefits that have been validated through past implementations.
- Less information to report (project team members)
- Time and cost saving through reduction of the reporting effort on all projects
- More appealing to use
- Less information to review (management)
- Higher quality data (relevance, freshness…)
- Prevents information overload
- Straight to the point information
- Simple and easy to use
- No special skills required (non-threatening)
- More appealing to use
- Inexpensive to implement and operate
- Can leverage existing technology (see below)
- Does not require specialized resources to implement
- Flexible to implement and use
- Fully customizable to every organization's needs
- Can be used for other purpose (see Potential Use below)
While the approach may be very appealing, it is very important to take into consideration the change management aspect of the implementation (see Challenge below)
Implementation Considerations
Technology
While there are several ways to implement the proposed system, some simple technology, readily available within all organizations, could suffice to get started and benefit from it.
At a minimum, a spreadsheet containing the Project Mode, configured to comply with the Reporting Rules, can be embedded (defined as a template) in the public folder section of popular e-mail software such as MS Outlook or Lotus Notes. Each project has its own spreadsheet and the information can be easily accessed for viewing or updating, function of the authorization granted to the various users of the system.
The system can be further refined, without major complications, if shareware software such as MS SharePoint or Lotus Notes is available. Additional functionalities such as version control, automatic change notification and data consolidation at the program or project portfolio level could be enabled using the technology already in place.
Finally a simple custom web application can be developed and integrated within an organization's intranet. This approach provides the opportunity to expand the scope of the system to integrate other project data available elsewhere, such as financials or RAID (Risk, Assumptions, Issues and Dependencies) elements.
Challenge
The main challenge presented by the approach relates to change management in terms of departure from long established reporting rules; that is, even if nobody likes them, and everyone keeps complaining about them!
While meant to be simple and easy to use, the approach may be considered as a paradigm shift, especially as it relates to the Reporting Rules. The exclusive concentration on what has changed rather than what has been done and what is planned to be done can be disturbing to some people. There appears to be some loss of “security” of being able to document the work that has been done or effort performed rather than focusing solely on what impacts project performance.
In order to be successful, the transition to the new system must follow the same guidelines as any change initiative:
- Justification of the reason for change (see benefits above);
- Leadership: management must insist on wanting to see the data in the new format and nothing else;
- Pilot the new system on a few projects and demonstrate its use and benefits;
- Provide sufficient training;
- Extensive coaching and mentoring immediately after deployment in order to reduce any fear and increase the comfort level of the people using it;
- Exclusive use of the system for project performance monitoring in order to demonstrate that there are no other alternatives.
Potential Use
In addition to addressing the project performance monitoring information challenge, additional potential uses of the approach have been defined that further enhance its appeal.
Program and Project Portfolio
When dealing with a large number of related projects, performance monitoring becomes even more complex as the quantity of information quickly becomes a critical factor. The consistency of the Project Model and the consolidation potential of comparable data across projects, provide some relief in this regard.
Process Compliance
Since the Project Model is built from the organization's Project Life Cycle, it implicitly leads to compliance with the underlying project management processes. The Project Model can be enhanced, as needed, to track specific activities or deliverables deemed important by management or other compliance requirements (ISO 9000, Sarbanes-Oxley regulation). The nature of the data reported combined with the Reporting Rules provide an excellent starting point for any project audit activity.
Resource Allocation
There is a correlation between the level of effort required from a given resource and the various phases of projects. Mapping the resources to the current project phases, as reported, provides a high level snapshot of current workload as well as anticipated needs and availability.
Conclusion
To be successful in today's dynamic environment, where change is the only sure thing, the ability to track planned activities is more critical than ever. A simple, inexpensive, and easy to use approach has been proposed that addresses the information challenges encountered by all project stakeholders by offering better quality information with less data.
This approach, originally developed to streamline the reporting process, could become a method of choice in low project management maturity organizations where needs are the same as elsewhere, but resources are less equipped to deal with them. It would almost be like giving mice a roadmap to find their way in the maze in their quest for the disappearing cheese!