Tip of the Day - Estimating

When scheduling any task, especially a time-consuming task, it is always prudent to assume the task will take longer than you expect.  

Things happen.  

Therefore, add an allowance as a contingency.

This is not padding schedules for the purpose of billing higher.  Neither is it about covering your behind and ensuring you deliver before the target date.

It is simply common prudence.

If you believe a task will take 3 days and you promise to deliver it in 3 days, whoever is depending on your task may decide to commit himself to starting their task 3 days later, on the assumption that you will have delivered by that time.

If you fail to deliver as scheduled, then he will probably fail to deliver his task as well.  This chain could go on through to several persons.

Not adding a contingency to your estimate is not merely being gung-ho, it's plain irresponsible.

In addition to adding a contingency to your estimate, however, you must also be prepared to work on the next task if the current task gets completed sooner than scheduled.

Delivering on Scope

Many writers on project management tell us that project management is about delivering the project on time and on budget, with a special emphasis that project management is about the 3 constraints of quality, cost, and time.

Turner writes that project management is about managing the scope and the organization, and that quality, cost, and time are just constraints.  Consider that the reason for the project is the work to be done (in order to reap the benefits of the project). 

Without the work, there is nothing.  Next, consider that the project organization is what does the work.  Without them, there is nothing.  The other three features: quality, cost, and time are not the purpose of the project. They are simply constraints. 

Handbook of Project-based Management

Succeeding by not failing

We keep on building systems that experience failure mainly because we don't learn from our previous failures.  In fact, if only we made a formal effort to study the cause of previous failures, the 'vast majority' of failures would disappear.  This seems to be the thesis of a  book on system failures from Joyce Fortune and Geoff Peters.

The phrase 'system failure' normally brings up the usual suspect of 'computer/information system failure' , and that's not surprising. Information Systems chalk up more than their fair share of failures, or at least the failures that are interesting enough to make the news. One of the reasons is that these systems tend to have so much failure is that they are so embedded in organizational life that there are so many points of interaction and therefore so many points at which failure can occur.

Information Systems are also now so entwined in our social and cultural life that we experience failures almost every day, from a dropped internet connection, to a stolen credit card number.

 

While failures will always happen, a lot less of them would happen if only organizations made proper, formal reviews of what caused previous failures, and then apply the lessons learned, argues Fortune and Peters.   To aid in this noble aim, they have devised an approach called the Systems Failure Approach, an approach solidly grounded in the principles of systems thinking.  SFA lets its user extract failure events from the real world, construct a systems model of the failure using systems techniques and, from the understanding gained come up with a lesson that can be applied back to the real world.