Introduction

The world is a very different place for management. The signs are everywhere. Once upon a time, executives got months to make decisions. The fastest mode of transportation was ship by water or horse overland. Messages from one part of the country to another might take weeks to be delivered.

The advent of fast communications has changed that for ever. Now, with facsimile, mobile phones, the ability to direct dial anywhere in the world, email and, the ever- growing Internet, the world has become a smaller place. The effects are perhaps understandable but certainly have not been predictable. Manufacturing runs have become smaller because geographic proximity is no longer a significant factor in attracting and keeping clients. Your potential competitors now number every organization in the world who can manufacture what you do. Your goods could come from half-way around the world as easily as from half-way across town.

By the same token, organization who would once have been a local business now find themselves with inquiries from around the world thanks perhaps to a simple website on the Internet that a child could create.

This has many companies focusing on multiple small projects rather than one or two large projects. In fact, the day of the mega-project is virtually over.

A global shakeout of almost every industry is underway. Mergers and acquisitions of both similar and diverse firms occur as companies try to glom together to generate more protection from competitors around them.

As if this wasn’t difficult enough, the Year 2000 crisis means that every organization must update or replace virtually every core computer system it owns within a few short months. Never before in human history have so many commercial enterprises needed to change so much of themselves in so short a time.

It is no surprise that management schools of thought have undergone as radical a change as the factors facing them. There are entire new terms in our lexicon. Methodology such as Management by project, Results-based-management, Activity- based costing, Management by accountability, Management by Exception are all project management related terms.

Project management used to be the domain of a few highly trained technicians. People who worked either in the Aerospace/Defense or perhaps the heavy construction industry who had a particular perspective on producing pre-set results in a finite amount of time.

Project management has now become a public domain conversation. Even the most out-of-touch managers understand its basics tenets.

Yet, while project management terms have spread throughout the management community, the ability to deliver on them has been slower to realize. Project scheduling systems notoriously difficult to implement across an entire organization. Even with the widespread distribution of desktop systems such as Microsoft Project, the effort required for an organization to become more “projectized” is not trivial. Over the next few pages, we’ll look at how an organization can focus on implementing project control and what someone at the executive level of such an organization can do to make a difference.

The Dilemma

The last 10 years has seen a virtual explosion of project planning systems. In 1983, total licenses of planning software that were in use are estimated at approximately 100,000.

In 1998, total licenses of planning software in use are estimated at 7.5 million, led by Microsoft with about 75% of the market.

Planning software has definitely proliferated and management seems ready to change so what’s the problem? The problem lies in a cultural resistance of organizations to adopt such systems as a standard. It is perhaps no surprise that individuals are reluctant to adopt a system which will document their failure to meet commitments.

To add to this reluctance is a range of difficulties with commercial planning systems. The most distributed such system, Microsoft Project is characteristic of what are called “Desktop” planning systems. These systems are designed to make individuals more effective at managing their own project data at their own terminals. However, they are often poorly suited to integrating the project data of an entire organization. More advanced systems are available from several vendors but these systems are less widely distributed and therefore less known and are characterized by requiring more training by the end user.

All of this makes the implementation of such a culture change something to be taken on with some care.

Implementing a project control environment

The first stage is termed “planning”. This stage takes place prior to the actual start of the actual project work. During this stage, all elements of the project definition should be considered including a description of the actual deliverable, identification of which resources will be required to create it and a timetable of when the deliverable will be delivered. There are many planning systems which will be effective in this stage yet which are less able during the next phase of the project

The middle phase of the project is called the “execution” or “progress” stage. During this phase, the actual project work is completed. During this time, the project control system must be effective at collecting and comparing the actual progress with the planned progress. This requires gathering the effort expended, cost incurred and estimate of work remaining at the task level yet most corporate systems still capture this type of data by department instead of by project.

Napoleon Bonaparte is quoted as once saying, “A battle plan lasts until contact with the enemy.” So it is with project management. Once the project is started, rigorously tracking it against the original plan is crucial. Upper management almost always assumes this is being done yet if anyone were to ever audit the process, in many organizations they would find that progress information is derived, or assumed because existing systems simply don’t allow data to be collected.

“Surely not in my organization!” you say?

If you’d like to find out for sure, try this”: Call in one of your project managers and ask to see a “Plan vs. Actual” report on a current project (If he can’t produce one, it’s a pretty big clue). If there is such a report, ask two more questions: 1) What was the source of the data for the actuals figures and; 2) What kind of effort was expended to collect them.

In an organization which is operating more than one project at one time, the problem is compounded. Different project managers end up requiring that they approve charges made against their projects. Department level managers still must approve time for the time and attendance requirements of the organization. This classic matrix environment is becoming more and more commonplace.

With the diverse interests in place in an organization, multiple project control systems spring up. There is, after all, ample incentive for such systems. Project managers who have projects actually in production find themselves with a need to handle. Project by project these managers adopt systems that are available to them. One part of the organization finds itself using Microsoft Project, the next, Primavera. One department adopts Project Scheduler, another finds itself handling its information in a spreadsheet like Excel.

Trying to reconcile these project management systems is not a simple matter. Even high-end systems which have been successful in some organizations may be a struggle to implement in your own. This is partly because of the feature sets available in each system. Systems with features which make a system easy to use and thus easy to distribute to all the staff also make it likely that there is insufficient functionality or data architecture to bring such a system together. While Microsoft Project is now so widely distributed as to make its available virtually universal, an entire cottage industry of over 300 products have appeared as Microsoft Project “add-ons” trying to extend the use of the product for corporate-wide implementation. While some of these products make such a desktop tool more functional and more useful across an organization, they cannot change the fundamental architecture of MS Project as a desktop tool.

More advanced products like Primavera’s and Welcom’s Open Plan have tried to resolve this difficulty with creating both an easy to use product and a high-end product which can exchange data with each other. The functionality for these types of architectures is still in its infancy and while the concept is promising, it doesn’t solve the most compelling issue, one of culture.

In virtually all organizations, centralized control of projects requires a collaboration of personnel at different levels. Management must agree that project management will be practiced as part of doing business and that bad news from scheduling will not result in a “shoot the messenger” mentality. Middle management or project managers must agree to use systems that have some of their data originating from a central position (for example project priorities and resource availability.) End users must agree to provide accurate data to update the model.

In even the most progressive of organizations, the implementation of such a culture change is not insignificant. It may well take many months or even years to completely accomplish.

Yet the problems facing an organization are here now. Projects are underway now. Certainly some kind of project management is occurring now. What can someone do from management in order to most effectively implement a project control environment that provides visibility to management.

In an ideal world, project control systems would be implemented in the same way one thinks of a project: First planning and estimating, then project resource management, then project progressing and finally variation reporting. The tools for this might include: An estimating tool, a project scheduling tool, a timesheet system and an earned-value reporting tool. Yet, in almost every organization facing project management issues, multiple projects are already in place. In many organizations, the most common element of this structure already in place is the weekly reporting of time.

Implementing actual time reporting is often the fastest path to implementing the first stage of a project control system.

In most organizations, however the only centralized timesheet system is the one owned by payroll or finance. Project oriented systems are typically not centralized. In order to implement an organization-wide timekeeping system, a timekeeping system capable of serving both the finance and project management requirements must be implemented.

Benefits of automating timekeeping

That’s no problem for finance but for many project managers, the information from finance is not timely enough. After all, typically a finance system ends its cycle 2-3 weeks following a month end, making the information in that batch as much as 6-7 weeks old. That’s not very old for a finance report after all, this is an interim report of the financial year but for a project manager, information that is 6-7 weeks old might as well be from the dark ages.

Faced with this quality of data, project managers now turn to any solution that can be made available. Multiple timesheet systems appear; none reconcilable with the other. Perhaps this hasn’t happened in your own organization but it has happened in many.

With finance sponsoring most timesheet systems, it should also come as no surprise that the functionality included in them is consistent with their own requirements. What finance typically is interested in from a timesheet is: Who the employee is and the total number of hours spent during this timesheet period. Special codes for absence such as vacation and sick leave are also of special interest.

Conversely, project managers have almost no interest in how much time an employee was in the office or whether or not someone was sick. What’s of great interest to project managers is how much time was spent on their projects and what was worked on.

Timesheet systems which must work for both finance and project management must allow approvals to be done for both the department level or line-manager level and the project manager level simultaneously.
Note: For more information on timesheet approval systems which must work for both the organizational and project aspects of a business, see “A Matrix Approval Process for Labor Actuals” white paper by HMS Software here

Systems which can work for the entire organization carry other fundamental requirements as well:

• They must include the functionality required to track data needed by both finance and project management yet they must be simple at the end-user level. This means having a system with modifiable functionality.
• They must allow a complete audit trail to be maintained showing who has modified each line item of data and allowing data to be locked from people who do not have the right to change it.
• They must allow certain data to be restricted to certain employees. A project manager often controls data across many departments and thus might have to look at the timesheet data from just about any employee, yet while a project manager might look at the project costs for anyone, it is often inappropriate to allow a project manager to view the actual pay rates for every employee. Some information must be made available to certain users while other information will have to be hidden.
• The system must work across the database and architectural requirements of the organization. This means storing data in the database of choice of the organization.
• The system must be able to link to the organization’s finance system and also to whatever project scheduling systems may be already in use in a controlled fashion.
• It must be, of course, year-2000 compliant.
• The system must have an approval system which honors the organization’s business rules.

Once such a system has been identified, it will still need to be deployed. The good news about this is that in many organizations while it is not the most popular activity of the staff, filling in a timesheet is already considered a regular part of the week’s activities.

Once a project-oriented timesheet system is in place, the data it contains becomes of immediate value to management. Even if there is not a formal planning system or a budget-vs-actual reporting environment, many managers will be able to track problems with actual labor cost just from looking at the data. Roll-up reports by project and by phase allow a project manager to immediately identify time and money spent where it should not be. Also, the automation of such functionality immediately eliminates the most common error in manual timesheet: inaccurate charge codes. If hours cannot be charged to charge codes or tasks which do not exist or which are not yet open, a huge area of possible inaccurate charges has been eliminated.

Conclusion

Alternatives are not very attractive if your organization is pressed for results. High-end project scheduling systems can be implemented in several months for high-end users but this does not mean they will be deployed through the entire organization. This kind of cross-department collaboration takes many months or even years to accomplish regardless of how willing everyone seems to be on the first day of the project.

So-called Project Management Suites which include functionality for both scheduling and timekeeping may be worse choices yet. These systems are designed to be implemented from the start outwards. Thus scheduling and planning, as the first functionality usually thought of in the project management suite is often the first which must be implemented in the Suite product. Even though timesheets might have been easier to deploy culturally, they are often the last function which can be deployed in such a system. First, the entire organization must adopt the high-end functionality of the Suite.

Also, most Suite functions trade-off scheduling functionality for integration functionality. The project scheduler is either too high or too low or too generic for cross-organization use and the ancillary functionality almost always must follow the successful implementation of project scheduling.

This restriction has kept so called “Integrated” project management system approaches from taking a dominant position in the scheduling marketplace.

Any organization which commits itself to implementing a project control environment must determine its priorities. In some organizations, just making project management tools available for the individual use of project managers may be enough to make the organization more effective. The trade off here is that the tools will be adopted quickly and deployed to the limit of effectiveness of each project manager but the organization- wide visibility of the data from these products will be limited.

In other organizations a more extensive implementation of project management functionality will be desired where the data from multiple projects is amalgamated and the analysis for those projects is considered in the context of the entire organization’s requirements.

In these cases, implementing an organization-wide timekeeping system capable of handling both finance and project management requirements is likely the fastest path to implementing the first aspect of that system.

References

For more information on the advantages of implementing automated timekeeping, consult one of these white papers:

Why Automate timekeeping?

A Matrix Approval Process for Labor Actuals

About the Author

Since 1983, HMS Software has created timesheet system for mid to large-sized organizations aroudn the world. HMS is the publisher of TimeControl a project-oriented timekeeping system.

Mr Vandersluis can be contacted by email at: chrisv@hmssoftware.ca