Which are your best secrets/tricks to achieve project scheduling?

Question

Scheduling is so difficult. Don't you agree?

Which are your best tricks to achieve your scheduling target?

Answer 1

Agility.

Either (1) you're omniscient and can foresee all possible futures, or (2) you miss the schedule.

Since you can't make the schedule, you have to deliver value quickly and responsibly. Agile methods do this.

Answer 2

By doing realistic estimation, which means that the tasks must be identified to as detailed a level as possible (best if less than one-day duration tasks). This analysis can also help identify when requirements are not detailed enough. Some developers are not good at estimation so some history of estimates versus actual results can be helpful when trying to adjust expectations.

Answer 3

Figure out what you need to do. Break it down into tasks. Make an honest guess at how long each will take. Then add a fudge factor to each task, and a fudge task to the overall schedule. This isn't dishonest - you need to allow for things going wrong and for other tasks to steal your resources occasionally. The more experience you get with a specific team or a specific type of system, the more accurately you can estimate the tasks and the less fudge factor you will need.

As part of this, identify your external dependencies and make a plan to deal with each of them not coming through. Stuff directly under your control has more uncertainty than you think, and stuff NOT directly under your control is worse. Practice defensive planning. Have tasks to build test stubs for external libraries and other interfaces. Assume you will need to build input scripts because that nice external GUI or service or what have you will not make its' date.

Speaking of defensive planning - if you get in a situation where you have done the above, and management reduces your schedule to meet a date or doesn't let you add the defensive tasks, keep records for yourself of what you recommended and what they made you sign up for. These aren't ammunition for a battle, they are metrics for you to learn from so you can adjust your approach next time if needed.

IMHO the specific methodology you use to schedule doesn't really matter all that much, despite the various scheduling methodology evangelists. If you figure out what you need to do, get management buy-in on a plan to do it, and do the work, the work will get done.

Answer 4

Do the riskiest items first.

That way, if there is going to be a scheduling problem, you know about it early.

Answer 5

Do the most optimistic estimate
And multiply it by two.

Answer 6

Design the system as detailed as you can before giving the estimate - if you have time for that - and factor-in enough interruptions and maintenance time for previous projects.

And then, lie about your estimates. Shamelessly. :)

Once the deadline is set, prioritize and resolve dependencies. Do hard things as early as you can.

Answer 7

It's near impossible to provide an estimate without knowledge of what needs to get done, what the team is capable of based on past experience and probable risks (also based on past experience. The basic steps are:

• break down what is required into reasonable understandable work elements, (work break down structure)

• assign each piece an estimate (derived from the people that will do the work)

• assign each work element a risk level such as high/medium/low where each risk level is percentage to add to the est.
• add up the work elements including the risk level
• add a risk level to the project as a complete element and add that in.

For example: Project A has 3 work elements A, B and C

• A is 5 days and low risk (10%) = 5 + 1/2 day
• B is 10 days and high risk (30%) = 10 + 3 days
• C is 5 days and med. risk (20%) = 5 + 1 day
• Total = 24 days
• Total risk level of project is med. risk (20%)= 24 + 5 days (round up) = 29 days.

---

The inclusion of a risk level for each work element make the estimating a bit more accurate (based on past experience) and then a total project risk (based on prior experience with the technology, internal/external business factors, etc.) - help remove the post 'sticker shock' reaction to lower the estimate to something you think the sponsors will accept (and give you more to show them).

Here's a great book on the subject of software estimation: Software Estimation: Demystifying the Black Art

Answer 8

a couple of my tricks are:

• break down tasks into small units, nothing smaller than 0.25 hr blocks (15 minutes). anything smaller than that and its too micro. your task blocks shouldnt be bigger than 8 hours either (thats to macro)
• dont forget to account for administrative tasks (e.g. making invoices for clients, setting up email addresses, uploading files to the live environment, etc) - those little tasks do add up

i have a bit more information in my article: Project Schedules with Google Spreadsheets

hope this helps

--LM