Showing posts with label experience. Show all posts
Showing posts with label experience. Show all posts

Scheduling in the 21st century

Surprise! In the 21st century the art of scheduling - and the joys of creating elaborate Gantt Charts  - is becoming less and less relevant.


Why is this so?


Because  - at least in the software world - projects are being delivered continuously!


As soon as there is something to ship, it can be uploaded to the web, and as improvements are made, they can be tested and shipped as updates.

However, there still are some large projects that need industrial-strength schedules.


The easiest way to schedule a large project, is to find out when the boss wants it delivered. This way at least one person will be happy with the initial schedule. :-)


How long does it take to write new software? The real answer is: "we don't know", since this piece of software has never being written. If it had been, then we wouldn't be writing it again.


Experienced programmers do have an idea how long it will take them; experienced Project Managers will know how to gauge that estimate and how much padding to add to it.


Padding:


  • When in doubt, simply double the number and add a week. "Many a true word is spoken in jest" aptly applies in this case.
  • As a rule of thumb, (based on years of creating schedules,) I believe that 40% of anybody's time is unavailable. Be it vacation, holidays, parties, meetings, sick leave, miluim (as reserve duty is  called in Israel) and other reasons that prevent people from working on their project.
    • The estimate you got always assumes they will be working 100% of the time. Always look at a calendar with all local holidays, check the company vacation calendar and speak to the resource in question.
    • Even if there's 100% certainty that none of the above will interfere, you still need to add in 20% for the predictably unpredictable.
  • An estimate will never include the following, which need to be added:
    • Integration - unless your project is a standalone application implemented by a single person. Every milestone will require at least 1 day of integration, unless somebody can prove otherwise.
      • Always get these proofs in writing... this will usually prevent the same person from contradicting you next time.
    • Testing
      • The testing schedule also needs to be padded, as above.
      • The testers will usually need time to learn the system, or the changes to the exciting system.
    • Debugging
      • Testing almost always uncovers bugs that need to be fixed.
          • This will affect the engineer's schedule for the next phase of the project.
          • This will require another day of testing, at a minimum.
    • Documentation
      • If needed, then assume it cannot be completed before the debugging stage.
    • Maintenance
      • Unless the engineer is new (and you allocate for the learning curve) you will have to add padding for them to maintain all the projects they have ever worked on. We have seen cases when senior engineers get no work done because they have a full-time job maintaining years' worth of legacy projects, and assisting (relative)newcomers to learn all the legacy code.
Now you can try create a schedule, which will be out-of-date before you finish preparing it.

In a future post we will discuss how often to update a schedule.

- Danny

Can a project succeed without a PjM?

Since a Project Manager's task is to ensure the meticulous coordination of projects from inception through to the finishing touches, can't a group of adults manage without one?

The short answer is: "No, they cannot."

There are 3 aspects to this answer:

1. Skill Set

Each person has their skills. Project Managers have skills that other team members do not have - or have not perfected - such as identifying all the required components for the project to be completed, making sure they are all being done in the correct order and ensuring their integration.

Without a Project Manager, a team will arrive at the finishing line only to discover that some crucial aspect of the project has been overlooked.


2. Cheering Squad

For some reason, people perform better when they have an audience.

Twice a year at Answers.com we collected money for Ezrat Avot. For the past few years I did the collection, starting with an email to the entire company.
Since everybody knew this charity fund, and they all planned on contributing, one would assume that a simple follow up email closer to the deadline would be sufficient.
However, when I ran a full campaign, with weekly colorful emails and other gimmicks, we collected a lot more money.

Why this is I do not know, but sports teams also seem to perform better when they have a cheering squad and their fans in attendance.

So too, a Project Manager with his constant updates, nudging and encouragement, creates this psychological affect of having people perform better.


3. Coach

One would assume that athletes who are intent on winning would be able to train without any help. Yet most - if not all - pro athletes have a training coach. Somebody who can advise them, cheer them on and provide feedback.

Sports teams also have coaches - some of which are paid a fortune. No self respecting team would dream of trying to win a league without a world class coach.

So too, a winning project needs an experienced and professional Project Manager to to ensure the meticulous coordination of projects from inception through to the finishing touches.


 - Danny Schoemann
  Lecturer and Consultant; Project Management, Risk Assessment and Crisis Control

What's in a name?

The End Game was chosen as the title for my blog about Project Management, Risk assessment and Crisis Control for a simple reason.

Imagine a tourist returning from Switzerland raving about the amazingly comfortable - state of the art -  tour buses.
When asked what he saw there, he answers that he didn't see anything; he simply enjoyed spending 12 hours a day on those fantastic buses.

A project that doesn't get to the final stages - the end game - and all the way to completion, isn't worth much, unless you're one of those involved in "almost making it happen" and having fun while doing so.

  • A programmer who wants the experience of coding in a specific language, for example, may not see the problem with an incomplete project.
  • Somebody who comes to work just to get his salary doesn't always care if his project reaches completion.
Otherwise, it's obvious why an incomplete project is worthless. Nevertheless, many - some say "most" -  projects (especially in the software world) do not reach completion.

The End Game of a project is where an expert Project Manager is necessary; somebody who knows how to identify the missing pieces, figure out how to integrate them and get to that magical moment when a project can be called "complete".

In this blog - The End Game - we will be discussing Project Management, Risk Assessment and Crisis Control from various angles, based on my 15 years of experience as a Project Manager, Controller and Coordinator, and my 30 years experience in the Software, Telecommunications and Internet fields. More about that in future posts.

Meet the author!

Do Projects Ever End Early?

Finally, after many years of thinking about it, my book, titled " Do Projects Ever End Early ?" is ready to download. Do Projects ...

Popular posts