Schedule, Jr.: Professional Scheduling in a Small Company

Alex S. Brown, PMP IPMA-C


Most scheduling techniques were developed to address the most difficult scheduling problems of the largest projects in areas like defense contracting and construction. Not all of these techniques translate well into a small-company environment. Small-scale project management is different and demands different approaches, especially when project managers are inexperienced.

While classic techniques like critical path hold some value, many “introductory” or “basic” techniques of project management do not scale down well. Instead, more certain advanced techniques become critical, especially risk-based scheduling.

Mitsui Sumitomo Insurance Group USA (MSIG USA) considered implementing project-management software to help the part-time project managers who lead each effort. The project managers overwhelmingly wanted to keep working with familiar office-productivity software, after reviewing the specialized scheduling software available. Current software products are oriented towards larger schedules and teams, and do not necessarily provide value to all project managers.

A Disclaimer

The views expressed in this paper come primarily from the author’s own experience, especially those at MSIG USA. These opinions have been reinforced and confirmed by discussions with project managers at other 100- to 500-person organizations. The author’s experience has been primarily in the Financial Services area, where projects are an important part of the organization’s success, but where project-oriented work is secondary to the operations of the firm. The views expressed in this paper reflect these biases. Little hard research has been done on project management at smaller organizations, and this paper does not present any definite conclusions. I hope this case study may help inspire directions for future research.

Small Organizations and Schedule Risk

Scheduling in a Small Organization

Small size is the greatest strength and the greatest weakness of the small organization. Projects are typically orders of magnitude smaller than at larger organizations. A complex project at a multi-national corporation might have a team of 100 or more people and a task list with thousands of activities. A small organization may have 100 people or less in the entire organization. Project teams are more typically ten to twenty people, and a complete task list might include 50 to 200 activities. Projects are often completed quickly, in six to eighteen months. Larger projects are rare; most larger efforts must be split into phases to achieve executive support and to produce results in a reasonable time.

With limited resources, schedules must be light and simple. One person can review and understand the schedule completely. By contrast, a large project, with 1,000 tasks or more, may require several people to maintain. Even someone scheduling such an effort full-time would take a day or more to review the schedule thoroughly. With 100 tasks or less, a single person can review a schedule and even explain it to someone new in an hour or less.

Risk Profiles for Small-Organization Projects

Schedule risk tends to be very high in smaller organizations. There is a constant threat that operational issues may overwhelm the project team, forcing the team to either pause or abandon the project. In larger organizations, the following practices can often reduce or eliminate these risks:

  • Dedicate as many project team members as possible to full-time work on the project
  • Set a high priority for the project, pulling scarce resources off of lower-priority projects as needed
  • Create a staff of full-time project managers with a professional, consistent approach to estimating, scheduling, and controlling all projects
  • Create a Project Management Office (PMO) to establish and support project management standards and professional-level skills

For smaller organizations, particularly where most people work on the operation of the business, not projects, these recommendations are not feasible. The following barriers stand in the way:

  • Most staff have many responsibilities, making it impossible to put any qualified team members on the project full-time
  • Swapping resources between projects is rarely possible, because each team member is often the only expert in their particular field and is rarely qualified to fill a different role in a different project
  • With a large variety of types of projects and a small staff, it is difficult to train enough project management experts who also have the skills to oversee the work of the project
  • A PMO of any kind is difficult to justify for a small organization; if one exists, it will be small and limited

Unexpected events can have a large effect on project funding, project staffing, and many other factors that influence the schedule. A large organization can shield an important project from many risks; projects in a smaller organization will feel the impact of every change.

Reactions to Traditional Scheduling Techniques

With shorter, simpler schedules, many project managers at MSIG USA found that traditional critical path techniques were only marginally helpful. At MSIG USA, we trained project managers in the use of network diagrams, work breakdown structures, and other critical path methods. Most students found the discipline of creating a work breakdown structure helpful, but they questioned the usefulness of the other techniques.

In their real-life project plans, schedules were quite simple. Scheduling logic was simple; most tasks could be done simultaneously in theory. In practice, resources were the limiting factor. Typically there were too few resources available to run the project as fast as the critical path would allow. Resource leveling helped to model these constraints, but they had few opportunities to optimize the schedule because there were few tasks that could be performed by more than one person.

Many of the classic scheduling techniques provided little value. They proved what experts already knew. Most of the new or unusual scheduling options that they offered were unrealistic for the organization.

The Need for Risk Management

The most difficult barrier to planning was the high level of risk each project faced. Aside from the risk that estimates were inaccurate, there was huge uncertainty about the number of hours per week that each resource could devote to project work. Most project managers were unwilling even to guess the expected duration of a task. Learning about risk management changed their attitudes. By setting expectations for uncertainty and risk, project managers were able to begin to plan and estimate..

In consultation with senior managers, we set a standard risk level of 80% for most estimates. Project managers were encouraged to create work and duration estimates such that they felt there was an 80% chance that they could meet or beat those estimates. Risk registers were used to track opportunities to improve on those estimates and to track threats to their ability to meet the estimates.

We also encouraged developing ranged estimates where possible. Ranged estimates and the risk register helped team members and sponsors understand the uncertainty of any schedule or budget. Project managers felt more free to make an estimate when they had tools to discuss and explain uncertainty.

Importance of Change Control

Many larger projects have multiple layers of control, from team leader to project leader to project manager to executive sponsor. Sometimes the authorization required for change is unclear. Who needs to know about a delay? How quickly? Depending on the span of control of each leader and the impact of the change, information about the change might only to different people at different levels of the project’s organization chart.

In smaller projects, it is possible to make each person’s span of control and authority much clearer. At MSIG USA we were able to set a company-wide standard for notification and control of budget, scope, and schedule changes. Project managers are free to override this policy with their sponsor, but a default policy is in place to set typical expectations. Most project managers use the default policy unchanged.

This change control policy helped the project sponsors understand their roles better, and provided project managers with more confidence when giving their estimates. Having a policy for change helped everyone to understand that change was expected and could be managed. Without a policy, project managers feared the consequences when a milestone was missed or a budget exceeded. Once the policy was introduced, they knew what they would have to do if an estimate was wrong.

Project Management Software in Small Organizations

Picking the best tool to create schedules for a small organization is difficult on many levels. Although it may seem easier to manage smaller schedules, small size presents new challenges.

Reasons to Avoid Scheduling Software

At MSIG USA, few project managers used formal critical-path analysis to arrive at project schedules. Often they gathered information about the people, time, and work needed to accomplish each deliverable, then estimated dates by reviewing a monthly calendar with the people assigned to do the work.

Project managers tried different scheduling software, but found that it took longer to develop the schedule with the software than on paper. Well-documented schedules required precedent/successor relationships, resource loading models, and other information to create the schedule properly. With many part-time resources and heavily resource-constrained schedules, a lot of data input is needed to use the tool. Creating a calendar for a full-time project resource may take a few seconds in scheduling software. Modeling a resource with different availability, depending on seasonal and monthly operational demands, may take several minutes or even hours per resource. The investment of time to begin using the software was very high. When experts could quickly figure out appropriate dates for the start and end of these small schedules, using software was unattractive.

Rather than use a scheduling software package, MSIG USA used a spreadsheet-based task list. A few project managers decided to use scheduling software, but they represented less than 10% of the total number of projects under management. By using spreadsheets, it is possible for each project manager to decide how formal or informal their process will be of creating a schedule. Project managers spent little time learning software and inputing data. Many of the project managers were new to project management and needed a few days of training in basic skills. Avoiding another day or more of software training for each project manager was a valuable benefit to MSIG USA.

Enterprise Features on a Desktop-User Budget

A small company, ironically, needs many of the features of a large-company installation of project management software. To see benefits from project management, a small company needs to coordinate multiple projects. With little time available to reformat reports or consolidate data manually, cross-project reports are very valuable. Prioritizing projects is important to avoid resource conflicts among scarce resources. Many software vendors consider these “enterprise” features. They are available only in the largest-company installations, with high installation, customization and licensing fees. Cost-justifying these systems in a small organization is difficult or impossible.

Fortunately, the relatively small size of the portfolio of projects means that information can be gathered manually and priorities can be set one-vs-another. At MSIG USA, a set of manually assembled reports fill the most critical functions that one of these more expensive solutions would provide. These reports are available on the company intranet. A standing committee of senior executives meets regularly to decide how to prioritize work; project managers can bring any conflict they see before this committee for a final decision. Often the project managers and sponsors can resolve conflicts on their own, because company priorities are well-understood.

Resource Planning Challenges

One capability MSIG USA has not been able to re-create manually is tracking and planning resource use across the organization. This feature is the most valuable potential benefit of scheduling software, according to company project managers. This feature is the single strongest reason for considering an enterprise-wide project management solution. Because of the frequent conflicts for a scarce pool of skilled people, it would be helpful to have reports showing people’s availability for the upcoming months. Viewing the amount of working time needed by each person across all projects would also be helpful.

The greatest difficulty in automating resource tracking is the fact that a relatively small proportion of employee’s time is spent on project work. Few employees are full-time project team members. Most team members are giving just a few hours per week for a short period of time, contributing to small deliverables on one or two projects in a year.

Most project management software assumes that all or most of people’s time are spent on project work. Often they are implemented in organizations where project work is the primary function of the company or department, and operational or maintenance work is secondary. At MSIG USA the primary goal is to run the insurance company, and the projects typically are of secondary importance.

Many of the project management software tools actually require non-project work to be tracked as a separate project. The managers who own the resources need to enter the expected number of hours that a person is available for project work, while operational work is treated much like time off or vacations. When most resources are full-time experts working to run the company, it is difficult to get any manager to acknowledge that they have time available for projects. They will make time when asked, but few software packages support the concept of negotiated or variable availability.

Scheduling software could be useful at MSIG USA by reporting the total use of resources across all projects, but those reports would have limited value. Manually reviewing all the resource assignments for all active projects showed that it was very rare for the same person to be involved in more than one project at the same time. These reports would rarely help to avoid conflicts. The key resource conflicts were with the operational work of the firm. The few project-to-project resource conflicts were obvious to the project managers involved, even without scheduling software.

After review, MSIG USA decided that software alone could not solve the resource planning challenges. A change of thinking would be needed to get useful data. Resource needs for the operation of the company would need to be better understood to make the tool useful. Project management software providers could change their software to make these cultural changes easier. Allowing the software to gracefully handle operational staffing models as well as projects would make it easier for companies like MSIG USA to adopt their products. Collecting all operational work in a special “non-project work” project plan and forcing the data into resource calendars are awkward solutions that are hard for operational managers to use.

Possible Future Software Solutions

Some recent developments in project management software and scheduling have offered hope that more appropriate software solutions will become available for small companies.

  • Shows a range of possible end dates from January 2 to April 17. The height of each bar shows the number of scenarios where the end-date fell in that range. The distribution ramps up from January and falls off in April, and there are spikes and troughs throughout the curve. After running hundreds of scenarios, Monte Carlo software can show the number of scenarios that result in a given end-date. These charts help people visualize the probability of different outcomes.

With increasing computing power, running Monte Carlo scheduling simulations is faster and easier. These risk-based scheduling tools are becoming more graphical and easier to use for the non-expert. Although expensive, the software is able to do run scenarios on uncertain estimates as no spreadsheet possibly could. The extra capabilities of these solutions and their ability to deal with uncertainty may offer enough benefits to justify their price. The distribution charts produced by running multiple scenarios can help sponsors and team members visualize risk and uncertainty (see Exhibit 1).

Web-based software is becoming more prevalent. Some of these software systems are considerably easier to use than typical desktop project management software. Enterprise-level features are built in from the ground up, instead of being an expensive add-on. Mature software titles were designed first to schedule single projects, with “server” or “enterprise” modules added in recent years to handle multiple projects. Most web software was built from the start with a centralized data base and multiple-project features. They can cheaply and simply coordinate multiple projects, making them better suited to smaller organizations. Some software, however, has become so focused on collaboration and other web-based capabilities that the scheduling tools have suffered. Basic critical-path capabilities may be missing; features taken for granted in desktop software may be absent in newer web-based software. Both the mature software solutions and the newest web-based offerings have important pros and cons.

Process Maturity in Smaller Organizations

Recently process controls and maturity models have become popular, including the SEI Capability Maturity Model (CMM and CMMI), PMI Organizational Project Management Maturity Model (OPM3), and various vendors’ versions of the Project Management Maturity Model (PMMM). Many models focus on the needs of the largest companies. Companies spend large sums of money on consultants to move through the various steps in the models. Small organizations face some unique advantages in this area.

The MSIG USA Strategic Planning Office, which oversees project delivery, recently went through an audit. The auditors examined project processes, especially scope, schedule, and budget controls. One of their recommendations was to document policies and procedures and to train all project managers in their use. This work would ensure consist practices across all projects in the organization. Their recommendations roughly correspond to the “defined” and “managed” levels of many maturity models.

We rapidly implemented all their recommendations. In a few weeks, I was able to draft the policies and procedures and review them with the project managers, sponsors, and other managers involved. A series of one-hour meetings launched them. Some of the policies and procedures documented practices that only applied to my own work; these only had to be written, and then they were automatically rolled out and implemented consistently across the organization. Training and consistent implementation is far easier when only one person is responsible for the work. MSIG USA adopted standard policies for schedule control and standard procedures for creating and approving project plans, including the schedule.

A flat, small, organization can rapidly establish consistent, defined policies and controls. Small size is an advantage when the goal is consistency of practice. With fewer people to train, consistent practice is possible quickly.


It is tempting to assume that scheduling practices at small organizations should be simpler or less mature than those at larger organizations. In reality, smaller organizations often face challenges that larger organizations can safely ignore.

The key to success for project management in a small organization is to approach project management articles, advice, and software critically. Some standard practices will work well, while others do not scale down. Recent developments like web-based software and portfolio management techniques promise to make project management even more useful to smaller organizations.

Small organizations should also embrace the special advantages of small size. It is possible to adopt and standardize processes much more rapidly than in a larger organization. Functions that may take a whole department or which may be split between many departments in a large organization may be done by a single person. Smaller organizations can be more nimble and adopt advanced techniques more quickly.

“Small” does not need to mean “less” in project management and scheduling.