EagleRidge Technologies, Inc.: Resources : Word Problems and Project Management, by Crystal Sloan

While we won't be performing any project management-related calculations just yet, it's time to make sure you are prepared to do them.

We live in an age of computers and calculators. Even so, it is an inescapable fact that a solid (100%) grasp of word problems using arithmetic, and graph problems using arithmetic, is essential to being a competent systems engineer, systems designer, systems developer, or project manager. Even the best program or calculator is only as good as the information you give to it. You need to have an idea of the correct results to calculations if only to recognize and correct the garbage in/garbage out (GIGO) situations which can occur when using even the best project management software.

I have seen many adult graduate students, all intelligent professionals going back for a second degree, and all long-time users of computers, given a simple project management scheduling change problem that takes 5 or 10 minutes to work out on paper (maximum), take literally 3 days trying to get the answer using project management software, and still fail. The students who eventually got the answer right were the ones who did the basic math of the problem on paper in a few minutes, then used the software toward that end. Of 18 students in one section, for example, only one solved the problem despite the powerful motivation of substantial extra credit on the final exam--and he admitted to figuring some basic numbers on paper after 3 days of struggle with the software, then readily getting the software into line. The students who expected the software to give the correct answer without any thinking on their part, all failed, sometimes spectacularly with costs and schedule far from reality, in ways that at work could get one fired, or perhaps worse, turned into a laughingstock.

In short, the software will not substitute for thinking. Good software will help you by minimizing repetitive tasks, but you are still left with the job of thinking, if only to check what the software has done. An example of a repetitive task at which good PM software excels is that of automatically recalculating project dates for you, taking the holidays already entered into account, when you change a task's resource allocations. However, you will only know that the program is giving you the right answers ( that is, whether you have entered the right information), if you have an idea of what the right answer ought to be.

The math used in project management can get pretty complicated for non-math majors, delving into college-level topics such as calculus, differential equations, and graph theory, especially when learning curves and team-related productivity overhead curves are taken into account. Not to worry, you won't have to use college-level math in this class! :) However, if learning and overhead curves are ignored (that is, if loss of productivity from learning or from coordination in a team is assumed to be zero or is assumed to be a straight line, not a curve), many scheduling and resource allocation problems in project management reduce to the familiar "word problems" introduced to most of us in 5th grade arithmetic, then repeated year after year through junior high and high school math classes.

The University of Maryland University College has no specific math requirement for admission except in some specific programs; however, a Bachelor's is required, and with that (according to the Admissions Office) goes an assumption that one has at least mastered grade school and early high school math. For this class, and for the larger world of project management outside academia, it is these "word problems," especially those dealing with "job completion," that you need to master. This means that you need to have mastered addition, subtraction, multiplication, division, fractions, decimals, and percentages, too, since these are all used in "word problems." If you cannot work one of these problems and say with confidence that you have the correct answer, then you will have trouble making practical use of project management software.

Most of you will already have mastered this material. To those of you who need a refresher, or are facing learning the material for the first time, I say this: there is no shame in not knowing something, and likewise there is no penalty in this class for not being up on "word problems" by Session 1. :) There is, however, shame in refusing to learn. While remedial classes in arithmetic problems are beyond the scope of this graduate engineering or management class--we already have more than enough graduate-level material to fill these few weeks--those of you who may need a refresher would do well to review that material on your own or seek individual tutoring from myself or others, until you have indeed truly mastered it. You will eventually need those skills, and others will expect you to have mastered them.

Here are some sample problems, very much like some you might have to face many times as a project manager. Of course, in the real world, you wouldn't have the hints given by the multiple choice format; you would face an infinite number of possible answers.

Use the following scenario for problems 1 and 2:

Scenario: Suppose all the programmers at your company have the same productivity, all always hit the ground running on each task, with no learning curve, and all can work together on the same projects with no team-related productivity losses. (Yes, these suppositions are unrealistic—a proverb says that adding programmers to a late software project usually makes the project even later—but these suppositions do simplify the calculations you will have to make.)

Further suppose that we have a project consisting of a sequence of tasks in strict finish-to-start precedence, so that each task must finish before the next task can begin: none of the tasks can be done in parallel. Programmers A, B, and C are scheduled to handle this project, all working together on all of the tasks in the sequence, for a total of 96 8-hour working days.

Using the above scenario: Just before the project is about to start, marketing announces that we need to move the finish date forward by 14 working days so we can have something to show for a meeting when the client passes through town on his way back from vacation in the Caymans. Programmer D is available and willing to help out. If you add programmer D to the team, what is the minimum number of 8-hour working days programmer D will have to work on the project in order for the project to finish by the new earlier deadline?

4 2/3
7
14
24
28
32
42
48
56
96
192
288
None of the above.

Using the above scenario: instead of moving the finish date forward by 14 working days as in question 1, marketing waits until 50% of the project is completed (on schedule, incidentally) before demanding that the finish date be moved up 24 working days. Assuming you have programmers available to assign to the project, what is the minimum number of other programmers you need to add to the original team of 3 to get the project done by the new earlier deadline?

1
2
3
4
5
6
7
8
9
It is impossible to finish the project on time under the new conditions set by marketing.
None of the above.

Answer the next two questions using Figure 2:

Figure 2: a CPM schedule, with durations in weeks.

A Critical Path Method (CPM) schedule is a reduced form of a PERT chart, showing precedence relationships between tasks (also called activities), and task durations. Each arrow is labeled with the task name and its duration.

A dotted arrow means the task has zero duration. Unnamed zero-duration tasks are sometimes used on CPM schedules to show additional precedence relationships between other tasks; these unnamed zero-duration tasks are sometime also called dummy tasks. In the above schedule, for example, the dotted arrow connecting C and G and pointing toward G means that G cannot start until after C is finished.

Each path is designated by listing the named tasks on the path in order from earliest to latest. For example, the path of task A, then task B, then task G, is denoted A-B-G, and has duration 9. Dummy tasks are not listed in the path designation. For example, the path of task C, then the dummy (zero-length) task, then task G, is denoted C-G.

Note: On the graph above, color is used only to clarify which task name and duration goes with which arrow. For example, Task E is of duration 4 and corresponds to the downward-pointing arrow on the bottom left of the figure. Both the label E/4 and the arrow that goes with that label are shown in green.

"The Critical Path is the longest sequence of dependent activities (Ed.: or tasks) that lead to the completion of the plan. Any delay of a stage in the critical path will delay completion of the whole plan unless future sequential activities are speeded up." (For more on critical paths, see Mindtools, the source for this quote.)

In Figure 2, the critical path is:

A-B-C.
C-G.
C-D.
E-F.
Both A-B-G and C-D.
All of the above.
None of the above.

In Figure 2, what is the maximum number of weeks that task F can slip without extending the end date of the project?

0.
1.
2.
3.
4.
None of the above.

Here are some resources that can help you check your project management math readiness, and help you get help if you find you need a refresher:

Word Problems for Kids -- Problems are rated by grade, for 5th through 12th grades. If you can do all these, you should be OK.

Word Problems on Job Completion -- If you can always get problems like these right, you should do just fine solving scheduling and resource allocation problems using project management software.

SOS Math -- Algebra -- Most of this page is beyond what you will need in this class, but the arithmetic links at the beginning talk about problems you should be able to solve.