Spreadsheet Models for Managers

Maintaining Forward Momentum on Your Project

It’s easy to maintain momentum on your project as deadlines approach. But the key to a low-intensity, high-value experience is maintaining momentum when the deadlines aren’t looming. Here are some tips for maintaining momentum.

As deadlines loom, you’ll probably find it relatively easy to get down to work on your project and then keep at it to meet the deadline. Somehow you’ll find a way to meet all your other obligations, stay focused, and get the work done on time. That’s how we know that you have all the skills and discipline needed to maintain momentum. The question then is this: Why is it so hard to maintain momentum when the deadlines aren’t immediately pressing?

This page describes some of the traps that cause many people and project teams to get stuck, or to progress far more slowly than they hoped. There are many traps, of course, because people are endlessly inventive, but here are some of the more common ones.

• Scope creep
• Late deliveries by a teammate
• Waiting for a delivery that isn’t late
• Getting lost in the details
• Debates about how to proceed
• Perfectionism
• Excessive realism

Scope creep

Scope creep is the gradual expansion of the scope of a mission, task, or project. The scope of a project is the totality of its goals, features, attributes, and capabilities. Thus, for example, scope creep in your course project might be the gradual addition of more and more inputs, outputs, or parameters. Or it might be the incorporation of new calculations to obtain a more “accurate” model.

We do try to help you manage scope creep by requiring that you consult with us before deviating from your proposal. But your first defense against scope creep is your own alertness.

Late deliveries by a teammate

Most of you have full-time or over-full-time commitments to family, job, or other courses. These commitments are usually manageable, but sometimes they collide, and something has to take priority over the course project. These situations, and other factors, can cause a teammate to be late in delivering some work that the rest of the team depends on. When this happens, some teams decide that they’re “stuck,” and just sit around waiting. That is often a serious mistake.

Instead of waiting, the team can move ahead by using a placeholder in lieu of the actual delivery. The placeholder should have many of the attributes of the work the team is waiting for. For example, if it is a sub-calculation of the model, and the results are a 4x12 range, create a space for it in the combined workbook, and fill in some numbers that are either random, or approximately what you expect from the sub-calculation. If the item is a section of a document, fill in the section title and any sub-headings you expect and move on. When the missing item arrives, insert it in the placeholder’s place. Color the placeholders to remind yourself that they aren’t the real thing.

This technique doesn’t work for everything. But it can be used far more often than it is used.

Waiting for a delivery that isn’t late

Sometimes teams wait for work, not because it’s late, but because it’s taking longer to do than the work assigned to others. This is a sign that the total effort has been apportioned unevenly. The placeholder technique described above is useful here, too, but something additional is needed in this case.

What’s needed here is more care in apportioning the work. Make estimates of completion dates for each teammate’s assignment, and try to divide things so that all assignments are completed at about the same time.

Getting lost in the details

As you’re moving ahead, you sometimes realize that you failed to recognize something that you need to implement (if it’s in the model itself) or write (if it’s in a document). You have two choices. You can suspend what you’re doing and implement (or write) it now, or you can push ahead with what you’re doing, and add the item to a to-do list for later completion. Many people choose to suspend rather than push ahead. That is often a mistake.

It can be a mistake not only because it slows forward progress on the original task, but also because there’s no guarantee that it won’t happen again during execution of the newly-recognized task. That is, if you start on task A, and then recognize that you need to accomplish task Aa, that might be OK if you can be assured that you won’t find a task Aaa to do while you’re doing task Aa. The problem is that the failure to have recognized Aa from the outset is often an indicator of incomplete understanding of task A as a whole, and that implies that the probability of later recognizing a task Aaa, Aaaa, and so on, is elevated.

Usually, a safer approach is to create a placeholder for task Aa (as described above), finish task A, and then return to complete task Aa. If you take this approach, you’re far less likely to get lost in the details.

Debates about how to proceed

Some teams get involved in long debates about how to proceed. In the real world, when real money or enterprise survival are at stake, these debates are often worthwhile. But for your course project, much of what gets debated in project teams isn’t worth debating.

If the controversial item is related to a question about meeting course project requirements, then it’s worth debating. If you can’t come to a resolution in a reasonable time, contact a staff member for advice.

If the controversial item is anything unrelated to meeting course project requirements, it probably isn’t worth debating. Keep focused on the requirements.

Perfectionism

Some teams spend time making their models or documents more “perfect.” Since absolute perfection is unattainable, this activity is a waste of time. Perfectionism is more likely to take over in areas in which the team is most interested. They like working in that area of the problem. Beware what you like.

Excessive realism

Excessive realism takes hold when people forget that they aren’t actually on the job. What you’re building is a course project. It won’t actually be used at work. The purpose of this project is to give you an opportunity to demonstrate what you’ve learned in this course. Anything you put into the project that serves other purposes, and which doesn’t add to your demonstration of having learned something in this course (such as improving fidelity of the model by 8%) might be worth doing at work, but it is of questionable value in this project. If you like, you can document in your final report what you consider to be excessive realism that you elected not to implement.

Last Modified: Wednesday, 27-Apr-2016 04:15:26 EDT