« September 2005 | Main | November 2005 »
October 31, 2005
Philippe Starck's Organic Forms
I noted previously about the new Duravit building designed by Phillipe Starck, and thought that the design even if a bit Claes Oldenburgian was nice and rounded. Now I find that even as the building is in the shape of the toilet, the toilet is in the shape of the buiding.
/StarckX_WC_BIDET2.jpg/$File/StarckX_WC_BIDET2.jpg)
Just doesn't look all that comfortable to me.
Posted by Jack at 01:25 PM | Comments (0) | TrackBack
Perty
Glen has a brief post critiquing estimating using PERT techniques which points out some of the issues with using a particular mathematical methods of schedule estimation. It is interesting that the one of the commenters on this article takes Glen to task claiming:
"... there are some quite famous scientists and mathematicians that created these techniques, but they were also proven by millions of projects executed by hundreds of thousands of project management practitioners."
Unfortunately that is false. The creators of PERT did it under time pressure and did not themselves believe they were anything more than "quick and dirty". They also fail to be famous. I can't name them, can you? I think the claim of hundreds of thousands of project management practitioners may be a bit overstated as well.
But what is funny here is that the commenter decided to back up the technique by appealing to authority. In my opinion, that is a last resort. What is wrong with quick and dirty that you can't defend it as a techique in its own right? The point to be made is that there is a middle ground, a spot on the curve where the cost of obtaining the information is much lower than the value of having it. Certainly the technique is better than guessing. Defend it that way rather than attributing it to nameless famous scientists.
Just so I am not mis-understood, I have similar issues with the way it was presented. Monte Carlo schedule simulation is just about as quick (here is a free monte carlo simulator and one for blackjack players too) and much less dirty. The goal should always be to maximize return on your methods. Once you get to the point where the precision implied by your results is greater than the precision of what you are inputting, you have gone too far. Focus on the quick and try and clean up the dirty part. Project managers should strive to be as effective as possible. Sometimes extreme accuracy is part of being effective, other times it is a hindrance. But in no case should you have to apologize for being quick and dirty if that is what does the job.
Posted by Jack at 10:20 AM | Comments (1) | TrackBack
October 29, 2005
Are we not men?
Just finished reading "The Island of Dr. Moreau" by H.G. Wells and "Holes" by Louis Sachar. They are not really related at all except in the literary trick of isolating the characters in inaccessible locations - an equatorial island in the first and a dry lake bed in the second. The Island of Dr. Moreau was notable for a couple of reasons. It is quite a seminal story and one can see echoes of it in more recent works. The following passage seems to be referenced by both Orwell and Devo:
"Not to go on all-Fours; that's the law. Are we not Men?"
"Not to suck up Drink; that's the law. Are we not Men?"
"Not to chase other Men; that's the law. Are we not Men?"
If you are cheap you can read the etext (click link above). It is a quick read.
Holes holds a different sort of interest. It is almost like a bit of magical realism for young people and Sachar does a great job of lacing all the elements of the story together. Also a quick read and should be available in any local library.
Posted by Jack at 06:53 AM | Comments (0) | TrackBack
October 28, 2005
More Friday Humor
In case you hadn't noticed there is such a thing as the Dilbert Blog. It complements the Dilbert.com site. RSS feeds available for both.
Posted by Jack at 10:55 AM | Comments (0) | TrackBack
October 27, 2005
Accoona?
Like any good blogger I read my access logs to see who has been reading. Lately I've been indexed by an Accoona robot. Accona claims to take its name from a song in Disney's Lion King - "hakuna matata". This is a bit hard to believe, but true. Anyway, they claim to be a search engine focused on US and China and are apparently capable of some staggering leaps of logic. The most humorous of these is extrapolation from what looks like a very small data set to the characteristics of an entire nation of over a billion people. Let's see how this is done. For reference, this information is taken from their white paper written by Ira Machefsky and John Fernandez which you can find here
The first thing they do is list the top 25 search terms on their Chinese site. Here they are:
Spring Festival 19%
Tsunami 12%
Car 8%
China 6%
Chinese IM software 4%
CEPA (HK business pact) 3%
Plastic flower pot manufacturer 3%
Copper 3%
Mifare MF rc-531 (wireless chip) 3%
Textile printing ink 3%
Car Audio 3%
Education 3%
AL Corp Musical Instruments 3%
Accoona 3%
Chinese railways 3%
Thermo 2%
Mongolian Software(Chinese WP software) 2%
Shanghai 2%
Elderly in China 2%
Insurance 2%
Emigration 2%
India 2%
Mosaics 2%
Lantern festival 2%
Laptop mother board 2%
From this amazing data they draw some incredible conclusions:
Fully 7 of the top 25 search terms have to do not just with business but specifically with manufacturing: “CEPA” (3%), a recently passed Hong Kong business pact, “plastic flower pot manufacturer” (3%), “copper” (3%), “Mifare MF rc-531” (3%) a wireless chip spec, “textile printing ink” (3%), “thermo” (2%), “laptop motherboard” (2%). Expanding to include general business terms finds two more search terms: “insurance” (2%) and, significantly, “education” (3%)
They go on and list the top 25 searches on their US server and get some results focused on hair care and what appears to be a single hit for "Game Cheats". Comparing the two they conclude:
There is a fascinating disparity between the Top 25 searches on Accoona’s U.S. and Chinese sites. The category profiles for the two sites are the inverse of each other. Chinese searchers are focused on manufacturing and education while U.S. searchers are focused on entertainment, celebrities and games (and looking for ways to cheat at those games). One significant consequence of this finding is that there is considerable opportunity for manufacturing and business-focused search in China, an area that Accoona has pioneered.
If you are not laughing yet, let me tell you why I am. There are two reasons. The first is "plastic flower pot manufacturer". Apparently Chinese people care more about plastic flower pots than they do about the elderly, insurance and emigration, not to mention the entire country of India which shares a border with them and reputedly has nuclear weapons. Plastic flower pots are more popular than steel or heavy industry. Al Corp Musical instruments are more popular than Steinway. The Milfare rc531 is more popular than Chairman Mao.
The second cause for amusement is that all the results (which are stated in percentages - I find it hard to believe that their sample size was much more than a hundred or so) point to the success of Accoona's business model.
Is it too cruel to take the next step and claim that absurd "research" implies an absurd business? I don't know. It might just be self-serving propaganda. Ira Machefsky and John Fernandez are you out there? What were you thinking? Are you laughing too?
Posted by Jack at 09:18 AM | Comments (0) | TrackBack
October 26, 2005
What are you going to use Project Server 2006 for?
The news that the next version of Project Server is going to have "server side scheduling" is quite interesting. I think it is going to open up some new uses for Project Server. Uses that don't even require the use of Project Pro. If I had time and energy I'd be thinking about getting to work on a timesheet system which takes advantage of Project Server.
Of course, having scheduling available on the server also means that people will try to implement "real-time" scheduling, where the schedule reflects the impacts of the latest updates. This is a very attractive idea in theory, but in practice it has the problem that there is a level of uncertainty in the schedule at all times. You never really know if it is up to date. How many of the tasks are updated? And what was the status date of that update? It is often better to have an acccurate snapshot of where you were at a certain point in time than an impressionistic picture of where you might be now.
Posted by Jack at 04:13 PM | Comments (1) | TrackBack
October 24, 2005
Telling Time - ProjDateDiff, VB DateDiff and Application.DateDifference
Date subtraction in VB, Project VBA and Project custom field formulas is one of the more common activities. Unfortunately there are a number of slightly different functions available. This article briefly describes the main three.
It all starts with the VB DateDiff function.
The syntax is as follows:
DateDiff(interval, date1, date2[, firstdayofweek[, firstweekofyear]])
interval is required and is the time unit you want the result returned in:
date1 and date2 are required and are the two dates you are working with.firstdayofweek and firstdayofyear are optional and will change the defaults from Sunday and the week which contains January 1 to whatever else you might choose.Now this is a pretty powerful and useful function, but when you are calculating schedule dates it becomes a problem. The issue is easily illustrated with the example of a weekend. Suppose you want the working hours for a task between now and two working days from now. DateDiff would work fine if both days are in the same workweek, but once the interval spans a weekend then the calculation is wrong. To resolve this, Project VBA has the
DateDifference function. DateDifference is considerably simpler. Here is the syntax:Application.DateDifference(StartDate, FinishDate, Calendar)
StartDate and FinishDate are required. They are the start and finish dates used.
Calendar is optional. It can be a resource or task base calendar object. The default value is the calendar of the active project.
The result of this function is the duration in minutes. You can convert the minutes into days by dividing by 480 (for an 8 hour day or more accurately dividing by 60 * HoursPerDay. HoursPerDay is a Project property which reflects the current definition of workdays in Project. You can also divide by the HoursPerWeek and DaysPerMonth functions if you want to use longer timescales.
Application.DateDifference is what you would use in VBA code.
In Project custom field formulas the situation is almost exactly the same. However instead of being called
DateDifference, they named the function ProjDateDiff. The arguments are the same:ProjDateDiff( date1, date2, calendar ) and the result is also returned in minutes. Converting this into usable time periods IS different though. Custom formulas offer the
[Minutes Per Day] and <[Minutes Per Week] constants to do conversion to days and weeks. There is no month conversion available.
Here are a couple of examples:
Project VBA DateDifference example:
Sub projectduration()
MsgBox CStr(Application.DateDifference(ActiveProject.Start, ActiveProject.Finish, standard))
End Sub
Custom Field Formula Example:
ProjDateDiff([Project Start],[Project Finish],"standard")
Note that the custom field formula requires quotation marks around the calendar name and the VBA example does not.
Posted by Jack at 11:32 AM | Comments (0) | TrackBack
October 21, 2005
Mano a mano
I've thrown THIS in the ring at Josh's Gadget Fight. I doubt it can win as it has no flashing lights or ringtones, but it is still going to be around years after most of the gadgets are retired to the scrapheap.
Posted by Jack at 09:49 AM | Comments (1) | TrackBack
October 18, 2005
Pareto and the 80/20 Rule
Glen asked what the "underlying principle" for the 80/20 rule is. So instead of letting things get lost in the comments I'm going to give a brief summary of what I know about it.
Vilfredo Pareto was a French-born Economist who on studying land distribution in Italy found that 80% of the land was owned by 20% of the population. Essentailly he found that land distribution followed a power law probability distribution and conveniently 80/20 happens to be one of the most easily spotted points on the curve. You can see that when I graph it in excel a big red arrow shows up and points at it! I'm not familiar with all of the mathematics behind it, but it does serve as a useful rule of thumb and has been adopted by many people as a "rule".
With the easy availability of large data sets (website log data) and the use of excel, it seems to show up quite frequently. In an internal blogging system where I work the ratio of posts seemed to follow this "rule"
Well, it seemed to follow that rule until I realized that I counted all people with a blog and 1 or more posts. If I added in the bloggers who had never posted it threw the curve off. Anyway, fundamentally I think it is more of an observation than a rule. Juran, who you might know from his work in quality management took the ball and ran with it creating the Pareto Principle and derivatives thereof.
That it fits certain observed phenomena is interesting in the same way that PI or PHI (1.61803398874989... also known as the Golden Section) is interesting. As Glen has pointed out to me it is also related to Theodore Sturgeon's maxim that "80% of everything is crap". This and a bit of recursion will get us most of the way to 100%. I'll leave a little room here at the bottom to keep the ratio golden.
Posted by Jack at 09:57 PM | Comments (2) | TrackBack
The 80/20 Rule in action
With a little more than a quarter million hits to this blog I thought I'd take a look and see who is responsible and the results are that 80% of readers are responsible for 20% of the hits. Leaving the top 20% of "readers" responsible for 80% of the hits. 
Most of the top 5-10% of the "readers" are search index robots and rss readers who hit the site several times per day. Thanks go out the percentage of my audience which is living and breathing.
Posted by Jack at 12:37 PM | Comments (2) | TrackBack
Boys boys...
Glen and Brian are both interpreting what they think I said here. All I can say is that blog comments as a means for discussion are far from being an optimal method. Oh, and also that they are both right about certain things.
Posted by Jack at 12:13 PM | Comments (1) | TrackBack
October 14, 2005
Take a tour around the world
Visit Pruned and BLDGBLOG for some alternate views of the world around you.
Posted by Jack at 05:12 PM | Comments (0) | TrackBack
October 13, 2005
The Nattering Nabob
Sometimes I get comments like this:
> Ok I've read all the back entries...
> It would appear that your philosophy is essentially they (meaning project management tools) don't work in their
> current form and therefore we don't need them.
I'm not sure how people draw this sort of conclusion. I think at least half the posts here are about helping people use tools like Microsoft Project more effectively than before. There seem to be two classes of people, those who think criticism is about polishing out the scratches and dents (me) and those who think that finding flaws in parts is a precursor or excuse for trashing something in the whole. I suppose it boils down to whether you believe criticism is constructive or destructive.
So my warning to readers, if it appears to you that I have trashed something dear to you, I probably haven't. However, that thing might have a mustard stain on the shirt that you should try and take care of before it sets.
Posted by Jack at 12:36 PM | Comments (0) | TrackBack
October 11, 2005
In an Imperative Mood
Read these articles:
blogging style by Joi
humans by Josh
On a very tangentially related note, I just finished Great Expectations by Charles Dickens. I'm kind of surprised that I've not actually read any Dickens before and equally surprised that I found it so enjoyable. About two thirds of the way through you will find the derivation of the title of this post.
Posted by Jack at 10:00 AM | Comments (0) | TrackBack
October 09, 2005
Calculating a Critical Path Schedule using CPM
I've mentioned that calculating the critical path in a schedule is fairly trivial for a modern computer and is possible for a determined person with a pencil and a big sheet of paper. However I haven't explained how. Fortunately I ran across this article by Mike Glen which tells all about it..
Posted by Jack at 10:12 AM | Comments (1) | TrackBack
October 06, 2005
MS Project VBA - Earliest Predecessor
Sometimes we want Project to calculate a schedule a little differently than it does naturally. At least a few times I've had people ask if it is possible to set the start of a specific task based on the date the first it's predecessors completes. With a little code it is easily possible. This code takes the predecessors of a selected tasks and figures out which is the one which will finish first. Then it applies negative lag to the dependencies between itself and the other predecessors. The comments in the code (lines starting with an apostrophe ') describe what is being done
Sub FollowEarliestPredecessor()
Dim t, p, earliest As Task
Dim ps As Tasks
Dim l As Long
Dim tdeps As TaskDependencies
Dim tdep As TaskDependency
Set t = ActiveSelection.Tasks(1)
'Set lag to 0 to remove any previous lags
Set tdeps = t.TaskDependencies
For Each tdep In tdeps
If tdep.To = t.ID Then
tdep.lag = 0
End If
Next tdep
CalculateProject
'Find earliest predecessor
Set ps = t.PredecessorTasks
Set earliest = ps(1)
For Each p In ps
If p.Finish <= earliest.Finish Then
Set earliest = p
End If
Next p
'Set lag so it covers the greatest task variance
l = -Application.DateDifference(earliest.Finish, t.Start)
'Apply that lag to all predecessors except for the earliest
For Each tdep In tdeps
If tdep.To = t.ID And tdep.From <> earliest.ID Then
tdep.lag = l
End If
Next tdep
CalculateProject
End Sub
Pretty simple.
Posted by Jack at 07:27 PM | Comments (0) | TrackBack
October 05, 2005
Survey - Tell me what you like
Well, the experiment with surveys was certainly shortlived. I didn't know it would pop up a window which touts my ISP. Perhaps it is best if you just leave comments. Thanks to anyone who did leave a comment. I'll see about putting together some more stuff on VBA.
Posted by Jack at 11:35 PM | Comments (1) | TrackBack
October 04, 2005
Object Oriented Scheduling - Part I
I mentioned in a previous post that traditional CPM scheduling is rather primitive. It has only two major objects, tasks and dependencies. You might suggest that resources are also worthy of considering, but actually in software like Microsoft Project it can be argued that they are a bit of an afterthought. My contention is that tasks and even the schedule itself is but one facet of a project, but before we get to building a better model for that let's look at how the current model can be improved. One way to do this is to improve the behavior of the tasks themselves. We can do this by adding additional properties or parameters which will change the way the tasks behave under different conditions.
The first and one of the more obvious properties of a task is the elasticity. We know that some tasks are quite fixed in duration while others are more flexible. Indeed, it is common to desire a task which will stretch automatically for the length of a project or a certain phase of a project. This sort of task is often called a "hammock task" and the method for creating one in Project is rather convoluted. Between the two extremes there are a range of flexibility in the durations of tasks. This may be due to the availability of resources upon demand (brought in to keep a task on schedule if necessary) or perhaps a lower priority or maybe the task results in something "nice to have" rather than something required.
Current scheduling software can not distinguish between the black of the fixed duration and the white of the hammock task, and as a result minor shifts in a flexible task impact the schedule projection to the same extent as a task with a hard duration. We can work around this by adding lag to the dependencies or other tricks, but ultimately we have to exercise judgement in determining if any slip is "real".
To get around this and to maintain a more stable model, consider adding a property to a task which determines its flexibility. Here I model the property as a spring.
Springs have a constant "k" which describes their flexibility. We could simply add a k property to tasks. A higher k would indicate a very stiff task and a low or 0 k would indicate that a task was quite flexible. Using the values of k and a measure of how much schedule pressure there is, we could obtain a more realistic model of how the work will actually be performed. Calculation of a network made of springs is more complex than the traditional critical path, but it should be nearly trivial for a modern computer. Why don't we start doing this now?
There are several more properties and methods I'll be describing in the coming days. Your comments are always welcome.
Posted by Jack at 06:15 AM | Comments (5) | TrackBack
October 03, 2005
Everybody loves Raymond
Bill Raymond that is. Bill is a Microsoft Project MVP who works for Pcubed. He has started a blog here and states that:
"You will get thoughts on using the Microsoft Office Project platform, updates on news and upcoming events and the occasional restaurant recommendation."
I had dinner with Bill last week and I can say it is probably worth subscribing to it just for the restaurant recommendation - though I don't see any appearing yet...
Good luck with it Bill!
Posted by Jack at 12:13 PM | Comments (0) | TrackBack
Microsoft Project - Not the center of the universe?
Yes, it seems that way. Looking at the latest public announcements from the PDC it is becoming clearer to me that with Project Server becoming a "work management platform" the traditional function of Project as a critical path method (CPM) scheduling tool has finally become just a feature on a larger platform. I'm wondering how long they will take to start calling it something like "Microsoft Work".
But from what I have seen, the transition is not a particularly graceful one. I think this is because they are working from a situation where the thought is "how do we extend project?" when the real question to be asked is "if we have a new platform, what should project be? Are there ways to schedule besides CPM and variations like CCPM (Critical Chain Project Management). But that is only the tip of the iceberg.
It seems to me that we have not moved far from the traditional deterministic models of tasks and dumb dependencies created so long ago. In most areas, computers have proven to be a major help in helping us to compute things which are impossible to do manually so we have fundamentally changed our processes and even the results of those processes. At one time in structural engineering it was (nearly) impossible to calculate the loads on certain structures unless the loading and the connections were idealized (effectively becoming pins and rollers). For this reason, trusses were quite common as there was a method of resolving the forces and loads across each member and the engineer could have confidence that the design would be sufficient.
With the aid of the computer new analytical methods became practical. Things like finite element analysis now allow us to solve what were previously indeterminate problems. Project on the other hand is little more than a box of blocks (tasks), sticks (dependencies) and nails (constraints). Calculating a critical path schedule of a hundred tasks is a job for a computer, but with a sharp pencil and a few hours time, one could easily do it by hand. Isn't it about time that this primitive method be replaced with a more accurate and more appropriate model? Now is the time to do it.
I have in the past proposed an object oriented schedule model. A model which moves from simple dependencies and elevates them to a level where they have relevant properties, characteristics, methods and events of their own. And a scheduling engine which can resolve all of the properties and connections (no longer simple sticks and nails) and can read all the parameters and come out with a better result than just a simple duration. An engine which can find the areas of stress within the project. An engine which can determine where we have been both too heavy and too light in supplying resources. An updated understanding of what work and what dependencies is necessary to get to this point.
But even if this attempt were to be successful, it is still tainted by close association with project. My early model only concerned the schedule and how to calculate it. The information needed to determine this is a subset of the information needed to manage work. A new larger model is required. A new model of work. A platform which can serve many different methods of scheduling (not just CPM or Agile or CCPM, and is large enough to cover other areas of management. A platform with the relevant information to make managing work a reality. The scheduling tool is not the place to start. It is concerned with a subset of the necessary information. The platform IS the place to start. Eventually functions like scheduling would be features of the platform and just as a word processor allows you to write a sonnet OR a specification, the platform would allow you to create an appropriate schedule model for what you are doing.
I am not suggesting Project Server is that platform or even that it could be in the upcoming release. It is clearly not. At this time I do not have a clear idea of what such a platform might actually be. There are too many things to think about and too many engrained ways of thinking about it to solve it in a single post. But knowing that there is a problem and that there may be a solution is a good start. If you have ideas, feel free to contribute. I'll be posting here occasionally as I think things through.
Many thanks to Gary Chefetz for helping to draw these ideas out.
Posted by Jack at 06:27 AM | Comments (5) | TrackBack
