Friday, August 31, 2007

Frank Patrick on sources of project failures

Frank Patrick has published his thoughts on the sources of project failures. What is different from many such lists I have seen so far is his focus on real-life factors (common especially in corporations) like inter-project dependencies and productivity killing influence of multitasking.

Frank's list:
  1. "Failure to appreciate the impact of a multi-project environment on single project success

  2. Irrational promises made due to a failure to take into account the variable nature of task performance

  3. Irrational promises made due to a failure to take into account the statistical nature of project networks

  4. Insufficient identification of dependencies necessary to deliver the project

  5. Focus on (and active management of) only a portion of what should be the full project -- a true bottom-line value adding outcome for the sponsoring organization

  6. Reliance on due-date, train-schedule, and actual-against-budget-to-date performance to drive project performance, resulting in the wasting of any safety included in the project (to account for 2 and 3 above) and in the effects of Parkinson's Law -- Work will expand to fill (and exceed) the time allowed

  7. Wasting of resources through underutilization because they aren't the "best resource" for the job

  8. Wasting of the "best" resources through over-utilization, multi-tasking, and burn-out

  9. Delivering original scope when conditions/needs change. Flip-side: accepting changes to scope without sufficient analysis of impact on the project (or on other projects)

  10. Multi-tasking, multi-tasking, multi-tasking, multi-tasking, and multi-tasking. Commonly thought of as a key problem in multi-project environments, where resources are expected to address tasks from different projects in a coincident time-frame, multi-tasking also impacts single project durations (and wastes safety) when dedicated resources are expected to wear several hats"


Some of those sound very familiar to me. And how about you?

Saturday, August 25, 2007

Best practices in library design

John Resig presented some very interesting thoughts on a JavaScript library design based on his experiences with jQuery and FUEL.

John advises how to write a solid API (those ideas seem to be useful not only for JavaScript developers):

  • perform universal actions (like CRUD)

  • fear adding methods (defer to extensibility, less but more powerful methods)

  • constantly review and remove unused code

  • provide an upgrade path for deprecated APIs (plugins / extensions supporting obsolete methods)

  • reduce to a common root (by finding common usage patterns)

  • care about consistency (naming, arguments order)



Here is the presentation video:



Presentation slides are also available at SlideShare: