5
Managing the Project

Q:	How does a project get to be three years late? (with a nod to Frederik Brooks, author of The Mythical Man Month)
A:	One day at a time.

In chapter 4, you learned how to create a detailed project schedule that included a list of finalized business and performance objectives, a chart of project tasks, task dependencies, and people assigned to each task, as well as how long each task would take and the due date. Minimally you completed a project schedule with one name and one due date for each task to be completed. You learned the difference between effort and duration, and the difference between people and task dependency. You also learned how to choose the right tasks for a course development project leveraging the best methodology as a cheat sheet. Now it’s time for the project to begin—your project schedule will be your map.

Unfortunately, the minute the project begins, your map is out of date—this is why having a flexible structure is so important. Your project schedule will change often, probably immediately. Many of the deliverables that your customer wanted during the planning steps will have changed by the time the tasks begin. Changes may include new tasks, removed tasks, or changed resources, but the most common change will be that the time estimates are now too short. Scope, money, and quality constraints may change as well. In this chapter, you will learn how to manage normal, but inevitable change.

Philosophically, it is important to remind yourself that a change to the project schedule is not a failure on your part. It is impossible to completely anticipate all the things you’ll discover during the project before you get into the nitty-gritty. It is also impossible to freeze the customers’ needs, because business change occurs all the time. Keep yourself from getting too attached to keeping the project schedule the same; if you can’t embrace change, at least be prepared to roll with it. Keeping the project schedule current is much more important.

This is not to say that you will make every change requested of you. The focus needs to remain squarely on the project stakeholders who have requested that the learning objectives be met in order to meet the business objectives. This is a crucial point—it is not your project, it is their project. You are the manager of their request. They make the decision as to when to change to reflect a new need; you simply implement the changes. This is where the project governance plan you established as part of the project charter really pays off. Who gets to decide? Does the project sponsor know about the change request?

Project managers who try to fight the needs of the business as it changes spend a great deal of wasted energy. To communicate effectively about the trade-offs, you’ll need to manage change and troubleshoot.

Dealing with project change involves two steps: identifying the change and managing the change in an effective way. Establishing monitoring criteria is how you measure progress. As in chapter 4, a budget worksheet like that shown in Figure 5-1 will be of the utmost help to you.

Figure 5-1. Sample Project Budget Worksheet

Managing Change

It is important to point out that the phrase manage change is significantly different from the phrase control change. Misunderstanding the difference between the two is one of the most serious hindrances to project success. If project managers believe that they must control change to be successful, every change will damage their self-confidence, and eventually the project will fail, if only from self-fulfilling expectations. This downward cycle—with lowered self-confidence driving failure, which in turn reduces self-confidence, and so forth—occurs in many projects and seems to happen most during times of rapid change. This spiral effect is not limited to the project manager, and the project team members quickly “catch” the attitude, thus amplifying the downward spiral.

In contrast, if project managers remind themselves that change is going to occur constantly, then they are free to react in a thinking way to the changes, rather than in a fearful way. Being open to change is not something that most people can do naturally. Change requires diligence, inner work, assessment, and constant checking of attitude. This principle cannot be overstated—many projects have been disrupted by the project manager’s blindness toward change. Usually they believe that any change asked for shows that they are failing to manage well, which is clearly not true if you remember that the business owns the project, not the project manager.

The project manager may want to establish a repeatable and consistent change process prior to starting the project. This establishes the rules for how changes will be dealt with when they come up. Not all changes are equal and all disrupt the velocity of the project.

The project governance plan, which is part of the charter, can be used to establish this process. This plan clarifies who is able to make changes and what they can change. Combining the project governance plan created earlier with a simple process once the project begins can drive collaboration and prioritization success. Here’s a simple example process, which leverages a boat metaphor:

• A level 1 change is a small change, and could possibly wait. The boat is taking on water but could easily survive with a little bailing. Depending on how far along the project is, this change might be included in a future release and not dealt with immediately.

• A level 2 change is causing a bit more damage. The boat is taking on enough water that it is starting to sink; it could probably hang in there for a little while, but not indefinitely. This type of change is often a requirement that has been forgotten or a project deliverable that is not meeting the expected goals. The project manager will need to propose how to integrate this change and why to the project sponsor to keep the project on track. It may require additional time or money.

• A level 3 change stops everything, and requires the project manager’s immediate attention. Think Titanic. This type of change is extremely significant, and disrupts the project schedule.

The scope diagram created in the project charter is a critical document for determining whether something is truly a change. Many project meetings become arguments about “he said / she said” requirements when they are discussed without the common language of a scope diagram. Given the complexity of most projects today and the chaos of multi-tasking, change is a given. Scope creep, uncontrolled changes in a project, creates schedule, budget, and quality slippage. Scope creep isn’t always a bad thing, but it does interrupt the flow of a project. The scope diagram will never be detailed enough to resolve all debates, but it is a useful tool in the negotiation process.

The rest of this section describes how to use the project charter and project schedule to adapt effectively when change occurs, which it inevitably will. Together, the project charter, project schedule, and budget provide the dashboard to monitor the project.

Risks and Issues

In the project charter, you learned how to do a quick ’n’ dirty risk assessment, and if merited, a risk mitigation table. The project manager must remain vigilant in looking for signs that these risk factors are actually coming to fruition. Some of the signs that might indicate trouble along this front are:

• new stakeholders with different requirements

• a “we must build it here” attitude from the customer, which prohibits research or external help

• a “we must get it outside” attitude from the customer, which prohibits flexibility or creativity

• reluctance to attend early meetings, but insistence on changing things right before the due date.

One high-impact risk is the key business sponsor leaving, which always affects a project. It may stall the project if the project sponsor is the stakeholder who leaves. Without sponsorship, even for a short period of time, the project will flounder. As a project manager, keep your ear to the ground to mitigate this risk by:

• meeting regularly with the sponsor

• listening for rumors of reorganizations and asking the sponsor directly for clarification

• searching for backup sponsorship as a contingency plan.

Once a project begins, issues occur. This is different than risks, defined by the possibility of a problem occurring, which have not happened yet. Some project managers like to keep an issue log to keep track of all the open issues as the project prog resses. But tracking issues on a different document than the schedule can cause some disconnects. Project status meetings get mired down when the same issues are reviewed over and over because no progress has been made. Lack of progress happens because no one has been given a task to move the issue forward with a due date.

Rather than struggle to figure an issue out as a group during a meeting, assign a task to the best person who can help with a due date and put it on the schedule. This person will own at least the first step of resolving the issue, and will be expected to report back. Now your issues are not on a separate list, but on the schedule tracked like all other tasks.

Constraints

Another part of the project charter is establishing the prioritization of project constraints. Recall that only one constraint—time, cost, or quality—can be the top priority of a project at any given point it time, although over time, these priorities can and do change.

For an example of how constraints can shift, think back to the fictional case study from the beginning of the book. The order of constraints that the customer agreed to during the define phase was quality, time, and then cost. The project schedule reflects the importance of having a high-quality product, so many checkpoints, reviews, and walk-throughs are scheduled. Sending multiple customers and multiple developers to those meetings will take time and will have a significant labor cost, but according to the priority of the constraints, that is an acceptable trade-off.

However, what if on the first day of the project at the first meeting, none of the customer stakeholders show up? As you call them to see what’s going on, they each tell you that they are too busy with business issues to participate in the analysis meetings. However, they would still like to be involved in the final (not the preliminary) walk-through of the finished workshop, so that they can offer suggestions. Obviously, it is going to be impossible to deliver a quality product in a timely fashion without customer involvement. What do you do?

You call all the customers and stakeholders and ask for a quick one-hour status meeting. At this meeting, you tell them that you have stopped the project until they are available for the analysis meetings. You revisit the constraints and explain that if quality is truly the top priority (which also should be supported by business objectives that were jointly created in the project charter), then you need participation all the way through. Anyone who does not participate in the beginning will not be permitted to critique during the walk-throughs because of the second constraint, which is time. If new voices show up at the end of development, then the project will be forced back into a new needs analysis phase, which will seriously extend the timeline. Since cost is the lowest constraint, you suggest the following alternatives:

• Stop the project until involvement is possible.

• Dedicate a single customer to the course development process. This person will represent the views of others (which is their responsibility, not the project team’s) and will also be the only one at the walk-throughs.

• Hire some temporary help to free up the customers so they can participate (spend money to “buy” quality).

• Change the scope of the project and build a smaller course with good quality, reducing some time and cost of involvement.

• Adjust the constraints and the project schedule.

If these options do not work for the customer, then the behavior tells you that the constraints are not correctly prioritized. If the customers are unwilling or unable to spend time or money, as the above behavior indicates, then quality is not the first constraint. At this point it is important to revisit the constraint matrix (see Figure 2-3) and come to an agreement that is consistent with current behaviors. This may be a good time for the project sponsor to help you specifically ask for the type of help you need.

If the constraints change, it may create a need for additional stakeholders and tasks. Remember to update the scope diagram created in the project charter if this occurs.

Schedule

The project schedule can be created in two ways: You can assign milestones and tasks to dates by working back from a due date in which you do not put down a duration for each task. Or you can assign each task a duration, and let the project management software calculate all the dates for you.

If you are working back from a fixed due date, you will have to enter your fixed dates into the tools. Most tools will require that you put a number greater than zero in the duration field, but typing in a due date tells the software to ignore the duration of that task. Just enter “1” in the duration field for all tasks, and type in the dates you want to hit.

If you are not working back from a fixed due date and you are going to determine the duration for each task, let the software calculate dates from your task estimates rather than typing in dates. Doing so gives the software more flexibility to reflow the dates if the actual task time is longer or shorter than planned. Always view computer-generated charts with a good dose of common sense and watch for any unrealistic durations or dates that you have accidentally entered.

However you create the project schedule, it is vital to monitor how it is affected when change inevitably occurs—whether it’s adjusting your spreadsheet or revising the dates in the project management software. Change can easily derail a project if the project schedule is not kept up to date. Adapting the project schedule helps keep all stakeholders informed of any changes and thus aware of shifting due dates.

Budget

After the project schedule was created, you also created a costing worksheet. During the manage phase, the project manager must track the actual costs of the project and compare them with the budgeted costs. Most project management software packages allow you to manage dollars at the task level, and some people prefer to do the tracking on a simple spreadsheet. Either way, it is important to keep an eye on the costs. The quicker negative trends are spotted, the quicker you can take corrective action. Your company may require that project stakeholders log their hours on timesheets to accurately track labor costs. Clarify with these people whether they are logging effort (best) or duration (not usually tracked).

Troubleshooting

This section offers some tips for managing project problems. You will have project problems, and something will change. Keep a careful eye on whatever the project sponsor has determined is the third constraint priority of the project—this is almost always the place where there will be pressure for it to sneak higher in priority. For example, if a customer has agreed that the order of project priorities is time, cost, and then scope, you will immediately feel pressure from the customer to add scope to the project. You will have to balance additions without increasing time or cost.

Time

Time is almost always trouble because it is the easiest to measure. Many projects are given arbitrary due dates simply to have one. Any project date with a one in it, like September 1, is usually arbitrary, especially if those dates fall on a weekend! The first thing to do when you need more time is to challenge the due date.

If you find that things are taking much longer than you had expected, here are some other options:

• Best: Cut the scope of the project and roll out the objectives in phases. Do a great job on a smaller piece, deliver it quickly, and then leverage that success to roll out the rest. Much of the up-front bottlenecks, such as agreeing on terminology, the look of the pages, the exercise flow, and the overall form will be resolved by the smaller, first piece, thus easing the way for the later modules.

Risk: If the learning is not something you can subdivide and still get the job performance required, quality suffers.

• Might work: Get some money to add resources to the project. Outsource tasks that are chewing up lots of time, such as programming or video production. Hire an expert in a skill that your team lacks.

Risk: Adding people to a project always increases communication time and often can put you further behind. Remember—for every person you add to a project team, you lose 25 percent of everyone else’s time to bring that person up to speed.

• Probably won’t work: Ask for more time. If time is the first priority, this won’t work. If it does, it wasn’t really the first priority. It is always a good idea to test the constraints. If it does work, this is the easiest solution.

Risk: In projects, there is never enough time. Work expands to fill time.

• Bad idea: Pretend everything is okay. This forces everyone to deliver poor quality, creating piles of rework and distrust.

Cost

Surprisingly, money is a pretty difficult commodity for project managers to measure. If you have hired a lot of outside people to help; have purchased expensive software, hardware, or equipment; or have spent money on “hard” dollar items that are easy to notice, you will get pressure to reduce costs. Most training projects are avoid-cost oriented, so spending money is not popular. Internal people costs are somewhat measurable, although the numbers often are artificial. You may get pressure to cut staff to reduce costs. Project development hours themselves are pretty difficult to measure accurately, other than guessing historically with timesheets.

Here are some options for cutting costs:

• Best: As previously mentioned, cut the scope of the project, and roll out the learning objectives in phases. Do a great job on a smaller piece, deliver it quickly, and then leverage that success to quickly work on the rest. If people truly are cost conscious, adding phases will be well received.

Risk: If the learning is not something you can subdivide and still attain the desired level of job performance, quality will suffer.

• Might work: If your project stakeholders are not charging back hours for your project, you can ask for more time so that the resources that are currently allocated to the project can continue to work on the project. This avoids the cost of hiring contractors to finish the extra work.

Risk: If you are tracking labor costs, adding labor time actually adds cost (of hours for the work). Sometimes this is not an issue, depending on how closely hours are accounted for.

• Probably won’t work: Ask for more money to add extra resources. If money is the first priority, this won’t work. If it does, it wasn’t really the first priority, and you will get some money to add resources to the project.

Risk: Adding people to a project always increases communication time. If their time is not charged back to the project, you can trade extra time for less cost.

• Bad idea: Pretend everything is okay. This forces everyone to deliver poor quality, creating piles of costly rework.

Quality

Project managers often are emotionally surprised when quality becomes an issue. The customer wants the best and may have many ideas about how to improve the work for which you, as a developer, are the expert. The most important rule is not to let your ego get in your way—which is a difficult thing to do. As developers, we take great pride in our work and want to be appreciated for it. It is a humbling experience to be critiqued by a person outside the field. However, it is vital to remember at all times that the learning event is not your deliverable; it belongs to and is being funded by the customer. They are the ones who judge whether it is good. They are the ones who understand the business context in which it will be implemented.

Here are some other thoughts on how to handle quality critique:

• Best: If the change is within the scope, make it quickly. If the changes start to cycle (changing something back after it was changed to something new, which is not unusual), begin to log all changes so that you can explain to the customer the cost of the constant tuning. If the project has quality as the first constraint, you should be tuning regardless of cost and time. If it is not, inform the customer honestly what the changes are costing in terms of time and cost. Draw a line at what you can change for fixed-bid contracts. As with time changes, cut the scope of the project, and roll out the learning objectives in phases.

Risk: Negotiating changes is a major factor in the trust between you and your client. It is vital that you are honest about how you feel, both with yourself (difficult) and with your customer (easier, but still difficult).

• Might work: Ask for more time so that personnel who are currently assigned to the project can continue to refine the project.

Risk: Adding labor time can be a very destructive activity, especially late in a project. It requires people who are already struggling to get the work done to drop everything and bring the new people up to speed.

• Probably won’t work: Ask for more money. Money is commonly not useful for buying quality because it adds new people, which adds complexity to a project. It might work if you obtain money to hire an expert in a skill that your team lacks.

Risk: Buying outside help late in the project has the same risk as adding internal people to a project. It requires people who are already struggling to get the work done to drop everything and bring the new people up to speed.

• Bad idea: Pretend everything is okay. This forces everyone to get angry at each other. A project cannot be successful if the customers and the developers are at odds. Avoid this situation at any cost because it creates a negative reinforcing loop that is difficult to break.

History Tells Us …

Projects are always unique, always exciting at the beginning, and always terrifying once they actually start. There is no honeymoon period for a project manager—the glitches begin almost immediately. Keeping the project charter you created in the define phase close at hand and constantly keeping the lines of communication open between the team and the customers is the only way to drive project success.

Post the following nuggets of truth on your wall:

• Bad news early is good news.

• Manage scope to manage quality.

• It is the customer’s project, not yours.

• Change is necessary, good, and inevitable. It won’t always go the way you plan.

• You will learn something new in every project, every day.

Summary

In this chapter, you read about how to manage a project once it begins. To manage a project as it progresses requires the confidence to clearly communicate the truth while listening carefully to the customers’ needs. In chapter 6, you will learn how to review a completed project to build your expertise for future projects.

Practical Exercises

Now apply what you’ve learned. Referring to your own project and to the documentation that you created through the exercises in this book, consider these specific solutions to your own project.