Showing posts with label Gantt Chart. Show all posts
Showing posts with label Gantt Chart. Show all posts

Monday, August 20, 2012

Dear PM Advisor August 20, 2012

Dear PM Advisor,

I've been told by my mentor to convert my 'Start to Start' relationships to 'Finish to Finish'. I don't understand why. I am testing my software and then recoding it based on my tests. I start recoding a couple of days after I start retesting. That sounds like a 'Start to Start' relationship to me. What am I doing wrong?

Depending on you from New York

Dear Depending,

Yours is a common misconception. Logically, the relationship between the two activities appears to be 'Start to Start' with a lag. Planning the project that way seems correct. You would give both activities the same duration, say 20 days, and set up the relationship as SS+2days indicating a two day lag between the start of the testing activity and the start of the recoding activity. So the recoding activity will finish two days after the testing activity. All looks good right?

But what happens when things progress and you will take an extra week completing the testing activity. You will update the Gantt chart by changing the duration of the testing activity. Now it will complete on day 25 instead of day 20. But since the relationship is SS, the finish date of the recoding activity will not change automatically. It will still finish on day 22.


So, even though the relationship appears to be 'Start to Start', think of the end of the activity. You cannot finish the recoding activity until you have finished the testing activity. So the real relationship is 'Finish to Finish'. And when you set it up this way and adjust the duration of the testing activity, the end date of the recoding activity will adjust automatically.


Not all 'Start to Start' relationships are 'Finish to Finish'. Examine each one with an eye to what would happen if the first activity was delayed. Then yo ushould be able to determine the real relationship.

Good luck,

PM Advisor

Send your questions to bfieggen@gmail.com 

Monday, June 11, 2012

Dear PM Advisor June 11, 2012

Dear PM Advisor,

Do you have any suggestions or tricks for printing a clear and visible Gantt chart of average size when you don't have access to a plotter? The Gantt chart I have right now is for one project which includes 70 tasks, it is printed on six separate 8 1/2 by 11 sheets that are taped together like a puzzle. So, in order to keep it legible, at least in 11 point font, are there places you can go who will print out? i.e. FedEx/Kinkos.

Blind as a Bat
Oregon

Dear Blind as a Bat,

You can certainly go to Kinkos, Staples or any office supply store. But I've never needed to do so in my 20 years of managing projects. I print it out on legal paper on the office printer. But first I need to get it to the right size. There are a lot of tricks to getting it down in size from the 3 x 2 sheets you are currently using.

Start by reducing the number of pages wide to only one:
  • First of all, print it on legal size paper.
  • Decide how many columns you really want to display.
    • By deleting a column, the data still exists and can be regenerated simply by re-inserting that column.
    • When you print out a Gantt chart, you only need to satisfy the audience you are printing for
      • They may not need to see the baseline start and finishes, the successors or any of the budget columns.
  • You can reduce the width of columns until numbers in there are reduced to #####, then widen them slightly to display the numbers again
  • When you've made the above adjustments, widen the column containing all the bars until it reaches but doesn't overlap the last column you wish to display
    • If you overlap even a little, that column won't print out.
  • Reduce the size of the bars to show just what you can fit on one page width.
    • You do that by pressing the + and - zoom buttons located near the right on the standard menu bar.
  • If you have an extremely long project, you needn't display all the dates. When you print you can select the dates that will be displayed.
    • Select File - Print then select the dates that you wish to print.
Now we'll reduce the amount of pages in height:
  • Get rid of the legend. Few people need it and it takes many lines from each page.
    • Press File - Page Setup and go to the tab called 'Legend'
    • Click on the choice 'Legend on' None
  • Open up only the summary tasks that are relevant to those who will be reading your printout.
    • Tasks that have been completed for a while or which won't be worked on for months can be rolled up to their parent summary tasks
    • Do this by pressing on the '-' sign to the left of the bold summary tasks.
    • You can open them back up when you need them by pressing on the '+' sign that replaces the '-' sign when you roll them up.
When you feel like you'll be printing out what you need, do a Print Preview before you print. Once you're comfortable, print it out, then tape the two or three pages together vertically.

Can anybody else add to these tricks?

PM Advisor

Send me your questions at bfieggen@gmail.com

Sunday, April 8, 2012

Round number estimates

I've managed a lot of projects in my life and have dealt with people making and then living up to, (more often not) those estimates of duration. I have found some people better at making and living up to estimates and some worse. Usually, those who live up to their estimates are not better at making them, just more dedicated to completing them within the time they estimated.

I once worked with an excellent woman who lived up to all her estimates. This was rare, but what made it rarer was the estimates she provided. She would be in the same room as the rest of the team making their duration estimates but when others would say a task took five, ten or fifteen days, her estimates were always six, twelve or eighteen; always some multiple of six.

I initially suspected that by giving herself an extra day of buffer she was more able to meet her deadlines but, after looking carefully around the room one day, I thought there might be a deeper-seated reason for her strange estimates. It took me a few years before I was able to verify my suspicions but finally, at a company picnic, I caught her unawares with her gloves off.

Just as I'd always suspected. People will estimate task durations based less on the complexity of the tasks and more on the numbers of fingers on their hands.

Friday, March 2, 2012

Earned Value Case Study

Using the Earned Value method of monitoring and controlling budget as described in the previous post, I have had almost entirely positive experiences with my clients. One experience didn't start out so positive.

Our project was to validate a computer system. We proposed the project carefully, using past information but making some assumptions based on information given us by our client. One of these assumptions was that the requirements document was in good enough shape for us to write a functional specification. As always, we made these assumptions visible as part of the proposal. (I'll have to write a separate post about the importance of doing this but you'll see how it helped in this case study.)

When we started the project, we found that the specification couldn't be started because the requirements document was in no shape to use as a starting point. We would have to rewrite this and then move to the specification. This meant more time spent on the project and more money.

So, when I showed up at the first status meeting with the earned value numbers, I shocked the client by predicting that the project would end two weeks late and cost an extra $10,000. They were livid!
"You're one week into the project and already you're two weeks behind schedule and $10,000 over budget!" was their response.

They were used to vendors keeping quiet about the overages and schedule delays until the project was almost over and then asking for the extra time and money. My boss was angry at me also because, frankly, that was the way he was used to doing business and he had warned me that being open with the customers was a bad idea. He was afraid we'd be fired from the project.

I met with the customer and explained the situation. I told them it was a good thing to find this problem early because they had the power to do something about it now. By explaining the cause of the overage and delay, I gave them three choices on how to proceed:
  1. Continue as we were going. We would rewrite the requirements, then the specification and continue the project. The project would cost an extra $10,000 and take an extra two weeks.
  2. They could rewrite the requirements document while we stepped away from the project, then return to restart. This would take at least 2 weeks (the client was super busy) but would cost no extra money.
  3. We would rewrite the requirements but the client would take over some of the later tasks (when their workload had diminished) to recoup the $10,000. This would cost them no money or schedule but would take some of their people's time later.
My client was amazed. They were given options on what mattered most to them: time, money or internal resources. They chose option 3 and the project finished on time and on budget. They confided with me later that they were so appreciative of the transparency of our methodology and their ability to influence the course of the project; something they had never experienced with any other vendor. The customer is loyal to us to this day.

Friday, July 1, 2011

How to plan a project

Here's an article I wrote a few years back showing how to plan a computer systems validation project. The methodology works for any project and it's the way I've been successfully planning projects for twenty years.

Project management techniques are universal. The proven, time-honored disciplines that make up project management can be effectively utilized and applied by virtually any manager, leader, or team member—regardless of industry, profession, or job title. The same skills I have used to develop and bring medical devices to market I have used to remodel my home and, most recently, validate pharmaceutical systems.

As Vice President of Project Management at QPharma, I train my project managers in a system I have developed over the years called ProgressixSM. The word is derived from three concepts central to my teaching:
  1. Progressive elaboration. The concept that a project needs to be elaborated progressively as we move from Idea*, to Purpose*, to Objective*, to Work Breakdown Structure*, to Responsibility Matrix*, to Schedule*, to Budget*, to Risk Analysis* to full Project Plan*. The project continues to be elaborated through execution and into closeout. (I first learned this order of project elaboration 9 years ago through a class I took from Cadence Management Corporation and have used it successfully since.)
  2. Six honest serving men. I use a poem from Rudyard Kipling to illustrate the key things that need to be known about a project to ensure a good, manageable plan.
I keep six honest serving men
(They taught me all I knew)
Their names are WHAT and WHY and WHEN
And HOW and WHERE and WHO

  1. Progress. Using the Tuckman Model, progress is made when the team moves from an awareness phase (which Tuckman refers to as FORMING*) through a conflict / control phase (STORMING*), a cooperation phase (NORMING*), and, finally, a productivity phase (PERFORMING*). This concept is evident with any group and is particularly useful in project teams.
So how do I go about this progressive elaboration? Let me use the example of a computer system validation we recently planned for a client. I became involved in a project that was already underway, because it was in trouble and the client had seen the success I had at projects in other departments.

The project was a corrective action tracking system. I was present at a very contentious meeting where two sides, the Clinical and the Information Services departments, were pointing fingers about how the project should progress. The meeting was very acrimonious, with little likelihood of any work being accomplished in the future.

Someone suggested I intervene, so I asked a simple question: “Who is the project manager?” Two hands rose, and I nodded, expecting them to glare at one another. But they had a different problem. One said she was the project manager from the programming group, and the other claimed to be the project manager from the users’ group. They added that they loved working together. I announced, however, that there can be only one project manager, and they needed to decide who it would be. The programmer was decided upon.

I requested that all the project participants, including the users and heads of the clinical and IS* departments, be present the following week at an all-day project kick-off session, which I would facilitate. They all agreed and, when the meeting time was decided, I sent out an agenda as shown below:

AGENDA
Time
Item
Led by..
9:00 – 9:05
Check in at room, Introductions
Bruce
9:05 – 9:15
Icebreaker exercise
Bruce
9:15 – 9:30
Project Background
IS & clinical heads
9:30 – 10:00
Project Objective
Bruce
10:00 – 10:30
List of Deliverables
Bruce
10:30 – 10:45
Break

10:45 – 12:00
Work Breakdown Structure
Bruce
12:00 – 1:00
Working Lunch

12:00 – 2:00
Responsibility Matrix
Bruce
2:00 – 2:15
Break

2:15– 4:30
Schedule
Bruce


I arrived early, and posted my responsibility matrix and schedule charts on all the walls. People were slow to arrive (is this an IT thing or is it just me?), but they were all present just before 9:30. I scanned the room and, sure enough, Clinical was on one side, IT on the other.

I started with introductions and then we went into a quick icebreaker exercise, which melted rather than broke the ice in that room. The one I chose was participant bingo, where I had a 5 x 5 matrix filled out with things like: “Drives a red car; Has more than three children; Loves the show Survivor,” etc. People tried to achieve Bingo by taking it around and getting people to sign their names in the appropriate box.

Next, I entered the six serving men scenario by answering the first question: WHY? Both department heads were able to speak their piece. Why are we doing this project? Why is it important to the company? Why is it important to the various departments and participants?



During this project background session, the location of the project, WHERE, was easily answered as only the US offices, nowhere else in the worldwide offices of this company

Then I took over. The room was clearly in a FORMING mode,