Project Management Tools | Get the Schedule Right!

Get the Schedule Right!

Project management tools and techniques help us  to do the job we need to do.  Yet, the tools can often become overwhelming with updating them, trying to get just the right report out of them, etc.  It is easy to lose track of what we are trying to achieve.  Estimating a schedule is one of the most critical things we will do so let’s see if we can get it right.

Is Your Project Estimating Facing The Diet Dilemma?

The diet dilemma is generally that everyone knows how to lose weight.  The crucial issue is the ability to carry it out.  There is a billion dollar industry that caters to “helping” folks lose weight.  However, the fundamental is that one needs to burn more calories than one consumes.  Simple?  Yes.  Easy?  No, not for many people.  Focusing on all the weight loss products, techniques and alternatives can easily obscure the fundamental of simply consuming less calories than one burns.  Once you get back to basics, then these diet techniques and programs, just like project management tools for a project, can vault you to success.  The trick is to keep your focus on the real purpose at each phase and to recognize the real reason why it is hard.

Get The Overall Schedule Right.

The classic method to setting a schedule is to call multiple meetings or send out multiple requests to get all the details and then roll them up into a plan and a schedule.  Inevitably the schedule is adjusted to meet the desired delivery or completion date.  Has this worked in your company?  Often, the answer is no.

Why not?  Because something was missed or something unexpected came up in the actual project.  Alternatively, you were given a schedule and told that is what your plan has to show in the end.  Your job is to figure out how to deliver by the given date.

How do you fix this in your project?  Call more meetings? Get more people involved? Include more details in the Gantt/WBS?  Get better project management schedule tools?

No.  This is treating the symptoms and not the causes.

The cause?  You don’t know everything up front that needs to happen or that will go wrong.  On top of that, if you could collect up and enumerate everything that must happen in the exact order, you probably could never finish recording it all, and you probably couldn’t find a tool that could capture all the details in an appropriate way.  Managing the project management tools themselves becomes a significant task (i.e., the diet dilemma) and starts to distract from managing the actual effort.

Collectively, however, you do know everything that needs to be done.  How do you remember a song?  You certainly don’t have every word explicitly memorized.  Instead as you sing the first part, the next part naturally pops to mind.  You have to sing the whole song to write it down.  The same is true for a project.  The catch is that to sing a project, you have to do the project.  The key is that what needs to be done comes back to people as they do it.  Again the classic approach is to try and figure out all the details in advance and to embed these details into something like Microsoft Project.  Instead, you want to leverage James Surowiecki’s “The Wisdom of Crowds ” in your planning. This becomes a balancing act between getting the key milestones and durations but leaving the details to the folks doing the work. One key detail is how to get a good estimate of the overall project time. This is often easier than one would expect.

Get The Schedule Right By Looking At Recent Projects.

You do have a record or data on previous, similar projects, yes? If so, you will want to spend time seeking evidence to one question: How long did it actually take? You will also want to do this with the actual people who’ve managed these other projects. Keep in mind that most people, no matter how intellectually gifted, simply will not remember accurately how long things took or where they spent their time.  So pulling data from records of actual projects is critical.  This is not always easy as project records may be hard to find.  The dates projects started and finished may not have been recorded.  Records that are kept may have been of the “last replan” and not of the whole project from beginning to end. Nevertheless, capture what data you can and see how long projects like yours appear to have taken.

So you now know, for example, that projects such as yours took about 12 months.  Some took longer and some took shorter.

The Most Recent Completed Project Is Probably How Your Project Will Go.

What has happened most recently reflects the net effect of: people + processes + tools + culture of your organization.  The chances that it will change significantly during your project is slender.  Many people would tell me that I shouldn’t base my project on the ones just completed.  “You will not have all the problems they had!”  Or they will say, “We have fixed all those problems!”  Don’t believe it.  It is a good goal, but it is a good bet that any non-trivial change to an organization will take years to have a true impact.  Of course, if a project was delayed due to hurricane Katrina, you probably need to base your schedule upon another project.

Expect To Have Problems You Can’t Anticipate.

But you can plan for them.  You just did.  By basing your schedule estimates on recently completed projects you’ve factored in many things that went wrong.  You will have some of the same problems. You will have some problems that were not seen by those other projects.  By using the track record of the previous completed projects, you have planned for a typical amount of things going wrong.  Many project management methodologies include a method of putting slack or buffers into the schedule.  Using recent projects naturally includes these items and does so based upon actual data rather than on guesstimates (e.g., add 10%, etc.).

If in fact your project delivery process is improving, you will still pick up these improvements in your schedule. Your project’s end results will show improvements. The next project that leverages off your experience will get your schedule improvements and build on them. What too many projects attempt to do is to spend their productivity improvements before they have any. I’ve often had to explain to folks that the new initiatives that intend to improve things by, for example, 20% will benefit the next project, not the current one. The initiatives that we will get the benefits from are those that were started in recent past projects. These are the improvements that are proven and mature and have become part of the process. Many improvement efforts never succeed.  You don’t want to base your schedule on the gains of a still theoretical improvement.

Trust People To Know How To Do The Job.

If you can’t trust them to do their job, you are in a real pickle anyway, and project management tools are not going to help. Also, these same people are the best ones to figure out that they don’t know something, or they’ve overlooked something. They are the best people to fix a problem in their area when it comes up. You want to empower them to identify and fix the problems. You have. You gave them the time they needed by the way you set the overall schedule.

If you have a classically compressed schedule, what will happen when a problem comes up? A milestone will slip and previous milestones have either also slipped or have certainly not come in early. You will ask for more status and regular updates from your team to explain to more senior management what is going wrong and how you will fix it. You might have multiple meetings a day. You will probably be having multiple meetings with more senior management. They will want more information and probably bring in “help.” The “expert” help will need more information. The “experts” will need time with the folks doing the work to get up to speed. Everyone will then pepper your team with questions. With meeting requests. With requests for updated status. If this is happening to you or typically happens on past projects, this is a good indication that schedules are not in line with reality.

Highlight Problems As They Happen.

Don’t panic, but don’t hide the problems. Show the problems as they happen and show how past problems have been resolved. They have been resolved, yes? If you have a reasonable schedule then probably yes. If you gave your team a reasonable schedule, they’ve probably also completed or delivered some things early and a bunch on-time. This also builds confidence so when something goes wrong, and it will, more senior management (and your management peers) will be more inclined to monitor what is happening rather than intervene in what is going on. If this is your first project or your organization consistently has problem projects, then you may get more help then you want. Your job is to have confidence in your planning and your team and to reflect that back to those trying to help.

Capture What Actually Happens In Your Project, As It Happens.

You will keep some kind of meeting minutes, yes? Status slides? Project plans? Keep and archive every version of the status and of the plan. If you find yourself “replanning” to fix a project, still keep the history that led up to the replanning. Most major projects I’ve worked on have been replanned numerous times. The instinct is to throw away all the previous data, slipped milestones, etc., because they no longer seem relevant and who wants to dwell on them. Yet, it is exactly this information that is most useful to the next project (your next project). The key insight is not that it finally took 12 months from the last replanning effort. The key insight is that a major project will get replanned three times over the first six months and then end with a final 12 month plan.

Planning For Problems Is Not “Planning To Fail.”

This one mystifies me. In one company for whom I worked, every product project we had leading up to the current project was late by at least three months. Every one of them missed their “final software” delivery point. We had to continue delivering new software many months after the date when the software should have been development complete. So while I showed the classic “final software” date in my plan, I also showed how we would fold in and manage any late software deliveries, since we always had them. “You are planning to fail!” was the reaction. On another project, when told by the software development team the date when they would be development complete, I asked them how we would handle any late deliveries that did not make that date. Their response was “we don’t plan for late deliveries.” I asked them how many times had they been 100% complete on the indicated date. They said never, but they would this time. I asked them how many times in the past have they made that same promise. They said every time. I asked them why it would be different this time. They gave me a list of reasons. I asked them if they had a list of reasons the last time they said they would be on time. They said yes.

There is a fear that planning for problems, especially a slip in schedule, communicates to folks that it is OK to be late or to have problems. It is not the plan that influences folks. It is the past history of such plans. At the same company I mention above, we always missed our ship date by at least three months. So the development teams knew they had more time than indicated, because they knew the schedules were unrealistic. They knew that the corporate culture required them to say yes they can hit the schedule but they also knew it was normal to miss it. At this same company when we finally gave the teams a realistic schedule, one that unsurprisingly was three months longer than we normally planned, we delivered the product on time for the first time in the memory of our largest European customer. Common wisdom would have suggested that by allowing three more months the team would have taken those three months and then added a few more on top of them. It didn’t happen that way. In fact, in over 30 years of managing projects in both government and industry, it never happened that way. The trick to on time delivery is to know how to set a good overall schedule.

Getting The Schedule Right Is The Best Thing You Can Do For Your Project.

In my 30 plus years of managing efforts, once the planned schedule gets a dose of reality, many of the regular problems go away. The critical problem that goes away is the inability to complete a project on time. Many other problems, that often look technical in nature, also tend to go away as we have now allocated the right amount of time to do them. This includes the time needed to handle the typical things that go wrong. Also, many of the existing management oversight procedures and processes tend to become obsolete. This is because they were generally put in place as a reaction to past schedule induced problems.

Padding The Schedule Is Not The Same As Getting The Schedule Right.

Padding in this case means to arbitrarily put in extra time. We want to put in only the time we need. That is why we base our efforts on recent completed projects that are similar to our own. When I mentioned above that we “added” three months, we really didn’t add anything. We just observed that it took us consistently 18 months to deliver a new product, but we consistently planned as if it took 15 months. If we truly believe our project will be more challenging than those that came before it, then we will pick the longer projects upon which to base our project.

We want a challenging schedule where everyone has to be on the top of their game to get it done on time (for reasons why, see 3 Secrets For Successfully Putting Your Project Management Team At Risk). We  want to finish exhausted but with success. People will work hard and long and keep coming back for more if the efforts are successful. Failures will wear them out. While many will continue to work their hearts out, we will not get the same productivity and creativity out of them that a successful effort would generate.

We can use all sorts of project management tools to help us get the schedule right. I’ve found that focusing on tools to get it right often encounters the “diet dilemma” where we spend more time on feeding the technique than on getting a schedule we can believe in. Once we’ve mastered scheduling based upon recent past performance, we are in a better position to get the most out of schedule estimating tools and techniques.

Filed Under Reporting, Schedule | 12 Comments

Tagged With Estimation, On-Time, Project Management Tools, Reporting, Schedule, Software, Tracking

Comments

Solutions

• Subscribe To These Articles

• Tools, Techniques, Hints & Tips

  • The Most Effective Part of the Day In Project Management?
  • Project Managers Repeat After Me: Software Development Is A Repeatable Process
  • Improving Project Management Productivity Does Not Save Time
  • One Reason To Always Support The Other Guy’s Project
  • Don’t Squash Your Project Management Pockets of Excellence
  • Don’t Kill The Golden Goose of Project Management – The Crisis
  • Project Management Crisis? Hurry, But Do Nothing
  • Project Management Initiative or Insubordination?
  • Your Project Needs Business Rules, Not Meetings
  • Project Management Or Anesthetized By Analytics?
  • Project Management or Death by Detail?
  • One Key Secret for Improving Project Management – Just Do It!
  • In Project Management 9+3 Is Not Equal To 12
  • The One Perfect Project Management Methodology
  • Three Reasons Not To Finish A Project Early
  • One Way To Make Your Project Risk Free?
  • 2 Ways To Make Project Management Problems No Big Deal By Managing Risk
  • 3 Secrets For Successfully Putting Your Project Management Team At Risk
  • Don’t Get Everyone Project Management Certified … For The Wrong Reason
  • One Great Way Of Using Your Project Management Staff Hours
  • Four Insights Into The Best Use Of Your Project Management Experience
  • Fixing The Project Management Plan: What Should We Be Doing?
  • Visibility – The Fifth Project Planning Secret
  • The Official Plan: Four Project Management Planning Secrets
  • Yes Virginia, There Is A Project Management Plan
  • Get Out Of The Rut Of Solutions That Don’t Work!
  • You Really Can Know If Your Project Estimates Are Accurate
  • Your Team Really Can Do A Great Job
  • One More Way To Fight E-mail Infoglut: Talk!
  • Don’t Treat Your E-mails As Dead Skeletal Husks!
  • Five Techniques For Overcoming E-Mail Infoglut
  • Using Hard Facts To Reduce Honesty Buffers
  • Nine Ways To Eliminate Honesty Buffers
  • Eliminate Your Project Management Honesty Buffers
  • Focusing On High Quality Gives You High Productivity At No Extra Cost
  • Project Managing Climate Change And Your Kids On Blog Action Day
  • It Should Work The First Time
  • Getting The Schedule Right Is Hard! But Not For The Obvious Reasons.
  • The One Key Step For Successful Improvements
  • The Busiest Software Test Organization Was Also The Best
  • Almost a Great Software Test Organization
  • Want To Stress Your Test Team? Give Them Good Quality!
  • Is Your Project Management On Steroids? Maybe You Should Kick The Habit!
  • Disrupt The Project To Make The Big Improvements
  • Project Management Needs Business Intelligence!
  • Global Project? Farther Away Can Be Better!
  • Are You Managing the Critical Project Thread?
  • Want Quality? Use the “B” Team.
  • Successful Projects Are Boring!
  • A Successful Manager But Never A Successful Project?
  • Project Managers, Are You Being Heard?
  • Does Anyone Really Care If Your Project Is On Time?
  • Is Your Project On Time?
  • The Ultimate Project Management Tool
  • Meeting Madness? Don’t Do it!
  • Seven Ways To Make That “Silver Bullet” Work
  • Avoid This Project Management Schedule Trade-Off Trap!
  • Knowing Your Project Management Average Is Powerful!
  • Being Slightly Out Of Control Can Be A Good Thing
  • The Leap From Mediocrity To The Exceptional Is Shorter Than We Think
  • Don’t Project Manage Change – Provide A Service!
  • Defect Reports Are Your Best Friend!
  • Get the Schedule Right!
  • If Nothing Else, Honesty Is Just More Efficient

• Browse by Category

  • Change Management
  • Communication
  • Personal Practices
  • Planning
  • Reporting
  • Risk Management
  • Schedule
  • Testing
  • Time Management

Tags

Change Management Communication Defect Arrival Rate Curve Defects E-Mail Estimation Honesty Honesty Buffers infoglut Initiative Measurement Metrics Military On-Time Productivity Project Communications Project Management Project Management Tools Quality Reporting Schedule Software Software Defects Time Management Tracking

• Recommended Resources

  • Blog Catalog
  • Blog Flux Directory
  • Blogged
  • Business Blog Directory
  • Cloud Computing
  • Customer Service Helper
  • Financial Project Management
  • Project Management Center
  • Search Open Directory
  • Software Engineering Institute
  • Softwarebuzz – Tech Blog
  • Spam Mail
  • Tom Peters
  Get subscribers