CASE STUDIES

Executing, Changing and Closing the Project

Additional lecture material from guest lecturer Dr. Donna McKalip, DM, PMP, Academic Director for Information Systems Management

When you, as the PROJECT MANAGER, are managing a project, you will always want to know where you are in terms of what work was scheduled, did it happen on time, did it cost what we thought it would cost and did we have the right resources assigned for that task. Easy questions, right? As the Project Manager, you will be MONITORING a project and that means keeping track of those cost and schedule and scope details so you know when you are in trouble, before it becomes trouble.

The points to remember are these:

You will assign/plan costs and resources and a schedule to every task in your work breakdown structure. You will need to know that everything is happening according to that plan. One of the easiest ways of doing that is to use your Microsoft Project tool. Once you load in the cost, resources and time, Project can show you where you THOUGHT you would be and where you ACTUALLY are. Let’s say it is mid-September (hard to think of September without thinking of the end of the semester and then the holidays are just ahead!). Let’s say you were supposed to have 10 tasks done by now and those tasks were supposed to cost you a total of $60,000. You check your Microsoft Project tool, which is tracking your actual time and money spent (if someone is putting it into the tool), and you see that you have 10 tasks done and you have spent $75,000 (more than the $60,000 scheduled). HMMMM and OOPS, something isn’t right! And now you have a reason to find out what is causing the problem.

Let’s say that it is still November and you have spent $60,000 but only 5 tasks are done (FEWER than the tasks you were supposed to have done in this period of TIME and for this much money). Hmmmmm, something isn’t right here, either. You were supposed to have 10 tasks done and have spent $60,000.

So to MONITOR the project means that you are able to compare:

· how much money you expected to spend for specific tasks versus how much money you did spend on those tasks (estimated vs. actual)

· how much money you expected to spend versus how much money have spent by a certain point in time, based on your schedule

· how many tasks you expected to have completed versus how many tasks you have completed

· where you are on the Microsoft Project schedule versus what date the day is (your schedule shows you should be finished with 75% of your project by September 1st. Today is September 1st and you are only 20% complete).

This is the essence of Earned Value . Earned Value compares what you planned or budgeted against what is actually happening. You will see a lot of initials associated with Earned Value (BCWP, ACWP, BCWS and EAC) – these mean Budgeted Cost of Work Performed; Actual Cost of Work Performed, Budgeted Cost of Work Scheduled, and Estimate at Completion. Don’t get panicky thinking you have to memorize these. As you work with them, they will become a natural part of your vocabulary. THIS is what managing a project is all about! Every day someone will ask you if you will be finished ON TIME (based on your estimate), or if you will finish ON BUDGET (based on your estimate), or if you will be able to provide what you promised (SCOPE). You should be prepared to answer intelligently based on EARNED VALUE. I thought I would be here, time-wise, but I’m here, instead. I thought I’d be here money-wise, but I’m here instead. I thought we’d be able to finish on time and on budget, but when the time is up, I’ll only have XYZ done instead of XXX and YYYand ZZ.

There are 3 essential formulas for determining EARLY-on if you have an overrun situation in time or money. These will be valuable to you sooner than you think! So, Earned Value is a method of monitoring a project by comparing the estimated cost and schedule to the actual cost and schedule (money and time spent). Earned Value compares the planned or budgeted cost and schedule against the actual cost and schedule, based on the work performed on the WBS tasks, and it helps the PM determine if the project is on schedule and on cost or running late or over cost.

Remember, the REAL value of using a Project Management tool, such as Microsoft Project is to be clear what tasks need to be done, when the tasks need to be done, what order they need to be done in, what resources and people to assign to tasks and when they the resources have to be available for the tasks, AND how much money each task will cost. This means that you are able to MONITOR your project using Microsoft Project and you will find problems while they are small problems rather than being surprised when the problems are BIG and almost impossible to solve.

For example: You have a sub-sub-sub-sub task, 1.2.2.1.3, for a very specialized software test to be done in July. This test requires a special test lab and a person with very specific skills. The task for the test is not on the critical path (there is about 7 days of slack before the successor task must be started). Today is June 15th. You just found out that the test lab had a small fire and all tests are being delayed. Your test will start 10 days later than you have it scheduled for. When you put the new dates into your Microsoft Project, you find out:

1. The task for the test has now become a critical path task.

2. Some of your successor tasks will now be late and will go on the critical path.

3. The end date for your project (when you will deliver) will now be 4 days later than you have agreed with your sponsor.

4. You needed 2 functional experts for a successor task (1.2.2.1.5) scheduled to be done in August. Because of the test delay, the successor task won’t be performed when it was scheduled (August 15). The new date for the successor task is August 20 but these functional experts will not be available on August 20 because they are scheduled to attend a conference. Now you may have a further delay as you try to reschedule the functional experts.

5. Task 1.2.2.1.5 with the functional experts had 12 days of slack time, but the predecessor task for the test (1.2.2.1) uses 10 days of the slack time. This task is still not on the critical path BUT if you are not able to find functional experts to substitute for those who were scheduled, you will add 5 more days to this task (from August 15 to August 20), and now this task will be late AND become a critical path task.

6. You may be able to find 2 other functional experts who can perform task 1.2.2.1.5 on August 15, but they are located in Singapore and you will need to provide air fare and travel expenses for them. Now you have additional costs for this task.

7. You go to your sponsor to discuss the problem and delay with the test lab and your sponsor decides that he/she will accept the project without this critical test. OR your functional sponsor goes to the supervisor of the 2 functional experts and convinces the supervisor that the project task is more important than the conference, and so the supervisor frees up the functional experts to do the task.

The point is, that a single, simple problem with at a sub-sub-sub-sub-sub task level could affect the entire schedule or the costs for the project, and by monitoring your project carefully, you will discover these small problems early enough to find work-around solutions OR be able to use slack and other means to stay on schedule and on cost. You now have visibility into potential problems before they affect your project. You are also able to communicate issues and problems with interested or involved people, managers, stakeholders, etc., and you are able to show these people the impact of problems.

CONTROLLING a project means controlling……. COST…… SCHEDULE…… and PERFORMANCE! How many times have we already talked about trade-offs among these three elements of project management? Almost every book you read about project management will have some good examples of things that can go wrong; or as I like to put it: Bad Things Happen To Good People!

Remember when we did the risk analysis and we listed everything we could think of that might go wrong with our project? Some of those things really will happen. Sometimes things will happen that weren’t on your risk list! In all cases, the project manager will want and need to control the changes required to get back on track.

There are several control methodologies. Here are the important points:

1. Change can be your friend. As long as you control the changes to your project so that you are able to maintain the balance of cost, schedule and performance.

2. To control your project, a project manager normally sets up a formal process for introducing changes that will impact cost, schedule and performance. This is called the formal change process, or configuration control, or change management. The formal change control process means that any changes to the project are submitted in writing and formally approved as changes to the baseline. You will control the requirements, the tasks, the WBS, the costs, schedule and deliverables or objectives. A project that is running late is going to affect cost. A project that is overrunning costs may mean that you don’t get full capability in your deliverable. For example, if you are building a house and the marble foyer costs $40,000 more than you thought and won’t be delivered on time – are you willing to make a change to your baseline and give up the marble foyer? Or will you pay the extra money and wait for the marble foyer? If you are in charge of moving your organization to a new building, but some of the IT and telecom won’t be ready on your move date, are you willing to pay extra for overtime or are you willing to delay the move? Control is making trade-offs…

3. Formal change control allows you to make the changes in a controlled way so that the PM and the project team can look at all aspects of the change. Another example: several years ago I was buying airplanes for the Air Force. One of the planes was new to the inventory and the contractor also provided spares. The Air Force was building hangars and maintenance facilities. The contractor wanted to deliver spares early. Several people thought this was a good idea. Since I managed the Project Schedule, I had to look at what else was affected when the proposed change came in. Here’s what I discovered: the spares were going to be stored in the maintenance facility, which was part of the hangar. The hangar was due to be completed 30 days before the baseline schedule for the delivery of the spares. If the spares were delivered early, there would be no place to put them – the hangar wouldn’t be done. AHHH – formal change control! If there had not been a process of review and approval in place, the contractor could have delivered spares and they would have been in the rain and snow for some period of time!!

4. The formal, written change should be reviewed by all involved in the project to see if the change affects other areas. That means the change is communicated through the project team. Then, because the proposed change will affect the baseline (remember the definition of the baseline is : the agreed upon cost, schedule and performance plus approved changes ) the change should be briefed to the stakeholders and senior management. So the proposed change needs to be communicated to all involved people, which is something worth remembering.

Here is a list of reasons for a formal change control system;

· To identify the impact of a change on all other tasks in the project

· To identify the impact of a change to cost, schedule and performance

· To determine the benefits to be gained by making the change

· To compare the benefits to the impact to costs, schedule and performance to determine if the change is worthwhile

· To identify alternatives and their impacts to see if the proposed change is the right choice

· To determine if there are impacts on any other aspect of the project (for example, the stakeholders, the team members, the sequencing of the tasks, the contracts, etc.)

· To determine the method to be used for implementing or introducing the change.

· To communicate to all involved that a change might be necessary, the reasons for the change, what’s involved with the change, and how the change will be implemented.

OK, now you know about controlling a project and formal change control.

Project Termination

So when IS a project over ?? I used to work for the Air Force and they STILL have a project office and a project manager for the some airplanes that haven’t been produced in over 30 years! Doesn’t the project EVER end ?

The simple answer is: The project is over when:

· The period of time for the project is over (a project has a definite beginning and a definite end).

· The deliverable has been delivered.

· The objective has been met.

· The purpose, such as moving to a new building or deploying the software, is complete.

Remember when we talked about planning the project, and I told you that your plans need to include plans for CLOSING the project? All projects have to end. If it does not have a specific end point, date or event, it is not a project based on our definition.

At the end of the project you have to send the people home, return the equipment, shut down the office and go back to what you were doing before. Your project is either over, finished and done, or the project becomes a normal part of doing business. Some examples:

· If your project was to move an organization into a new building and you have obtained and leased the building, had electricity and telephone wires installed, furniture delivered and set up, computers ordered and distributed, movers have come and moved everything, all of the people are in the building and all tasks that you defined and your sponsor agreed on are completed – YOUR PROJECT IS OVER. The building is now the normal place of doing business.

· If your project was to build a software application for a functional area and you have managed the design, development, test, training and installation of the software and people are using it – YOUR PROJECT IS OVER. The software is now a normal part of doing business.

· If your project was to install a LAN and you have ordered the equipment, installed the cabling, received the equipment, distributed and set up the equipment, loaded the software and tested the system – YOUR PROJECT IS OVER. The LAN is now a normal part of doing business.

· If you project was to start a new retail business and you stocked the shelves, hired the clerks, had Opening Day and the customers are coming in, your project is over. You are now running the business as the normal part of doing business.

I hope you now see the importance and VALUE of a very specifically defined end of project…

I’ll be interested in other examples. As a response to this Conference, you might wasn’t to provide us with some examples of projects and when they are over.

Some, most I hope, projects end just the way they are supposed to. Some projects end a little more “brutally”. If a project is WAY off base – terrible cost overruns or very delinquent schedules or unable to meet performance requirements, the organization may “kill” the project by terminating it. If the reasons for a project have changed, the company no longer needs it to respond to competition, or the company has been bought out or merged or new managers have been hired, the project may again be “killed” or terminated.

In general, there are 4 types of terminations. These would be useful points to remember for future project efforts.

1. Termination by Extinction – the project is stopped because it is over, because it is failing, or because there is no longer a need for it. Examples are a project delivery; an overrun project, or a technology that was overcome by newer technology (like Windows XP when Windows 2007 came out). This includes Termination By Murder, or termination for “cause” – and THIS is normally cost overrun, schedule delinquencies, inability to achieve performance requirements.

2. Termination by Addition – the project is added to the organization’s normal business process, therefore the need for the project is over. An example is a project to build a new product production line.

3. Termination by Integration – the project is absorbed into the organization. An example is a new software functionality that becomes a normal part of the business after all users are trained.

4. Termination by Starvation – this is when the money needed to make the project a success is not forthcoming; also known as budget cuts.

There are basically four things related to project termination, no matter what type of termination it is:

1. Resources, particularly the people. The project plan (yes, that PLAN that you prepared at the very beginning of the project) should address the people that will be needed and then what happens to them when they are no longer needed. Most team members go back to their functional organizations; but some organizations may move the team members to other projects. Other resources include the equipment, the office space and other things that were identified and used. What will you do with these resources when the project no longer needs them?

2. Contracts. Contracts should be completed, all deliverables accepted and final payments made.

3. Project termination, or close-out, briefings. A project manager’s last duty should be telling his/her managers and other related stakeholders the final status of the project and the disposition of all resources. This briefing should include the final status of cost and schedule and performance; budgeted/planned vs. actuals.

4. Delivery. The project, including training, preparation for operations, and preparations for maintenance should be completed and all relevant parties (usually those who signed the charter) are in agreement that the project is over.

As projects end, project teams often have an “end of project” party. I’ve been to many of those… some were a lot of fun, and some were a little bit sad, as we said goodbye to teammates with whom we worked closely. If we think of OUR CLASS as a project endeavor, we can celebrate your success! And I’m happy that you are that much closer to your own graduation!

To conclude our class, by now you should be able to discuss the factors that contribute to the success of a project and the reasons why projects fail. Those factors include all of those that we have studied and discussed and those listed in your text book. You should see that project management applies to personal AND professional projects. And, you have enough knowledge to go forth and BE a successful project manager! I wish you success in your future project management efforts!