This is part 2 in a two-part article about project management. For part 1, click here.

Let’s Talk About Schedule Pressure

On most projects, the scope of work to be done starts as a given, and is related to the requirements of the system to be built and the feature set to be implemented. Resources are always limited. So the variable to be determined is the project schedule.

How many of you have ever worked out a project schedule and presented it to your management or clients only to be told that you haven’t allowed enough time–lengthen the schedule by a few months?

PMP Training – Resources (Intense)

Think about those three knobs. Scope is constrained and Cost is limited, so little can be done about them at this point.

The result: management exerts schedule pressure. No matter what your original estimates say, management always wants it sooner. Why do they do this? They may cite pressure from their management, customers, the marketing department, etc. What they probably believe, at least subconsciously, is that you’ve padded the schedule and they are merely asking you to remove some of that padding.

Why would a project manager pad a schedule? Well, you may be forced into premature estimation, before you know enough about the scope or budget to give truly accurate estimates. You may not have used a productivity factor, but know from experience that your resources are not 100 per cent productive. You may also know of the tendency of developers to be overly optimistic in their estimates, they never foresee any problems or delays. Ideally, you should address all of these factors in your planning, before you provide a project plan and schedule.

Another factor that may lead to padding the schedule is anticipated changes. If you’re going to effectively manage any of the three constraints you’d better aggressively manage change of scope. Don’t anticipate, but do adjust, even for the most minor changes.

Schedule pressure can be insidious, and impossible to resist. I recently received a newsletter from Pat O’Toole, a fellow consultant, who claims that what management and clients really want is predictability. They think that if you give them a plan for 12 months and they insist on having the system in 10, that maybe they’ll be lucky enough to get it in 15. Look at your organization’s track record. Once you establish a record of delivering projects to your original estimates, schedule pressure will cease.

I once delivered a system on schedule in a large insurance company and was told that in no way was anyone ready to start user acceptance testing. They said that in the history of the organization no one had ever delivered a system less than two years behind schedule. When I reminded the client that he had insisted that he needed the system by a certain date, he responded that they didn’t really believe the date could be met but they might get it sooner by insisting on that date.

When can a system development project really be considered to be delivered late? I have a quote from an article I read when I was just getting started in this business that I think says it best: “The only time a project can be truly said to be late is when the project team has wasted time through lack of initiative or through poor planning.” Plan your work and work your plan.

Schedule pressure, if not resisted and eliminated through effective project management, leads to predictable results: Quality suffers, products ship “late” against an unrealistic schedule, budgets are exceeded, the system does not meet requirements as the scope gets curtailed to meet other constraints, and projects are canceled, usually because quality and risk were unmanageable given the pressures and constraints.

If you find you’re running out of time, it’s because you have problems that remain unaddressed.

How many of us have seen projects where first the schedule was extended, possibly several times. Then more resources were added late in the game to try to give “the big push” to the project; of course, Brooks’ Law then took over and the schedule was extended yet again. Finally, the scope was cut back, usually to the point where the system no longer met the objectives that originally justified undertaking the project in the first place. But the system, such as it is, gets implemented anyway and we charge on to a new project. Or, if we’re really lucky, we get to tackle Phase 2.

A recent client implemented a system months behind schedule, but had already initiated phase 1B, to correct the known deficiencies in the original implementation. Phase 2, where the real benefits to the organization were to be found, was delayed indefinitely, except by the Product Manager, a VP in New Product Development who insisted that the time be made up and phase 2 go in as originally planned, of course being staffed with the same people who had established the exemplary track record thus far on the project. GOOD LUCK.

Lack of time is the reason that most projects are forced to face other factors causing project failure. If you find you’re running out of time, it’s because you have other problems on the project that have remained unaddressed as you continued to extend the schedule.

Another Failure to Manage Scope, Cost and Schedule–Task Splitting

Task splitting, sometime referred to as multi-tasking or context switching, is a project killer. It acts very much like Brooks’ Law, only worse. It is the bane of the project manager’s existence. If you could change just one thing in your organization tomorrow morning to increase productivity, my recommendation would be to eliminate task splitting – the insidious practice of assigning people to multiple projects.

Why do I say this? The effect of task splitting is very easy to work out. Let’s say you’ve calculated your organization’s productivity factor at .7, leaving your staff 3 ½ days, or 28 hours per week, to work on projects. Numerous studies have shown that task splitting further steals productivity. Assign a person to one project and that person can devote 100 per cent of those 28 hours per week to that project.

How much would a project started today be worth to your organization in five years?

A good rule has been postulated and corroborated by observation. Assigning a person to two projects reduces overall productivity to about 80 per cent, due to increased interruptions, conflicting priorities, changing gears, etc. Assigning the person to three projects further reduces productivity to 60 per cent, leaving about 20 per cent of 28 hours, or a whopping 5 ½ hours per week of productive time for each project. Assign an individual to four or more projects and results are indeterminate. And you wonder why those seven projects George is working on never seem to get done?

Want further examples? Let’s say you have a project estimated at one man-year, 12 man-months, of work. Assigning one person to that project and applying your productivity factor of .7 will mean that the project can be completed in 17 calendar months. Assign two identical one man-year projects to the same person and both projects will be completed in 3 years and 7 months. For three projects, the time frame will be over five and a half years. This exceeds the expected employment of most IT professionals. These three projects are never going to get done. Even if they are completed, how much would a project started today be worth to your organization in five years?

Also note that, by tackling these projects consecutively rather than simultaneously, the organization has the benefit of the first system within a year and a half.

Why do we do it? That’s easy. IT management wants to tell all their users that their projects are actively being worked on, and they are reluctant to make the hard choices involved in setting priorities. “We haven’t forgotten the accounting department’s requests to put all our resources on manufacturing’s project.” We should know this is nonsense. Getting on my soapbox a little here, if IT management can’t figure out how to leverage its scarce resources to be the most productive and to provide the most benefit to the organization, then get some management that can do this. You think IT steering committees are the answer? Forget it. And just try explaining Brooks’ Law or task splitting to a steering committee.

What other factors affect the triple constraint? Definitely the project environment. How many of your developers have offices where they can work extended periods of time in relative isolation, uninterrupted by outside interference? Every industry guru who has looked at the software development environment–DeMarco, Lister, McConnell, Gilb, Boehm–has concluded the same thing. Developers need isolation and the ability to concentrate for extended periods of time.

Studies have shown that the average manager usually works on one thing for periods of less than five minutes. Developers need uninterrupted blocks of time of from 2 to 4 hours. Early in my career I was introduced to the unit of work concept: plan a block of work that can be completed in one sitting, and complete that work before taking a break or leaving work for the evening. We would design our programs and decompose them to the point where we felt comfortable that we had defined them in units of work. By doing so, we never had to return to unfinished work and waste time figuring out where we left off.

The larger the project, the lower the average productivity of project personnel, and the higher the likelihood of project failure.

Use of a contiguous or co-located work area for the project team has an obvious positive effect on communications and teamwork. Flextime is not appropriate for this type of work. Where you must use it, expect that productivity will decline, and use a lower productivity factor to compensate. This will, of course, lengthen your project schedule. Initial studies with virtual teams and telecommuting have also indicated significantly lower productivity, although some of this may be offset by the ability to work in relative isolation for extended periods, but who knows enough about the environment of telecommuters to say for sure?

How Does Project Size Affect Scope, Cost and Schedule?

The larger the project, the lower the average productivity of project personnel, resources are less effective and time is extended. Also, very large projects have better than double the chance of being cancelled. Remember earlier when I said that 25 percent of projects are successful? Well, that number has doubled since 1980; it used to be about 13 percent. Capers Jones says that the biggest reason for this is that projects are smaller than they used to be, not that we are any better at this work than we were 20 years ago. He also says that the larger the project, the greater the likelihood of its being cancelled. In the study I sited earlier, projects with over 5,000 function points were cancelled 50 per cent of the time and those with over 10,000 function points were cancelled 65 per cent of the time.

An easy explanation for this is that our current methods and tools are insufficient to control very large projects. Small errors or miscommunications can be fixed on small projects but may be catastrophic on a very large one. Project size is our enemy. Slice and dice, implement in successive iterations so you can maintain control. Tom Gilb, in Principles of Software Engineering Management, says that any project can be easily decomposed into successive small releases of usable functionality, and gives a method for accomplishing this.

A Few Other Project Management Factors

You must always pay attention to quality and to risk factors – poor quality and high risk can sink a project.

As I mentioned earlier, using small amounts of voluntary overtime can extend resources and/or shorten calendar time. However, excessive overtime will have the opposite result. Productivity, per hour worked, will decrease and error rates will skyrocket. Jerry Weinberg, my second favorite information systems guru, says that people work overtime on projects in trouble less to accomplish something than to not be blamed for project failure.

I mentioned the project manager’s control panel, with three knobs and two gauges. You must always pay attention to quality and to risk factors–low quality and high risk can sink a project. When developing system requirements, attention is paid to functional requirements but rarely to quality attributes, such as response time, maintainability, etc. When taking over a project for a client, the first thing I always ask is: “Who is the quality assurance manager on the project?” If the client doesn’t have one, I make procuring that person my first priority. On smaller projects, you’d better be your own Q/A manager. Quality must be managed from project inception.

Likewise, risk must be actively managed. Identify the most likely project risks and take steps to mitigate those risks. Do contingency planning. Two areas I always examine for risk are project turnover and the six level two key process areas (KPAs) specified by the capability maturity model (CMM). Until an organization can adequately demonstrate that these six areas have been addressed, consider each a risk to the project.

To summarize, a project manager must be able to define and control the triple constraint: the scope of work to be done, the cost of resources assigned to perform that work and the schedule, or calendar time it will take to accomplish the work. To do this job effectively, the project manager must understand and control the relationships and tradeoffs between these variables. At the same time, the project manager must actively manage both quality and risk.

References
Brooks, Frederick P. Jr. (1975), The Mythical Man-Month, Addison Wesley, Reading, Massachusetts.

Carnegie Mellon University Software Engineering Institute (1995), The Capability Maturity Model, Addison Wesley, Reading, Massachusetts.

DeMarco, Tom & Lister, Timothy (1999), Peopleware (Second Edition), Dorset House, New York.

Jones, Capers (1994). Assessment and Control of Software Risks, PTR Prentice Hall, Upper Saddle River, New Jersey.

McConnell, Steve (1998), Software Project Survival Guide, Microsoft Press, Redmond, Washington.

O’Toole, Pat (2001), “Do’s And Don’ts of Software Process Improvement #3 DO: Take Time Getting Faster,” Privately Distributed Newsletter from PACT.

Spett, Milton C. (1969), “Standards For Evaluating Data Processing Management,” Datamation, December, 1969.

Strider, Wayne (2000), Comments made at the AYE Conference, Scottsdale, Arizona.

Weinberg, Gerald M. (1992), Quality Software Management Volume 1 Systems Thinking, Dorset House, New York.