« December 2005 | Main | February 2006 »
January 31, 2006
Microsoft Project, the scheduling software people love to hate and hate to love
You can look here for some of the fun that is being had:
projectified: Glen is on a Roll!
I've posted about MS Project haters in the past. They are quite common beasts after all. On the other hand, those that "Love" Microsoft project are as rare as unicorns. Brian sticks up for it just because he is righteous and works for Microsoft :-). I think part of the problem is that it has a complex soul. It is hard to get close to it without accepting it on its own terms. It also carries a lot of baggage and thus is not as streamlined, simple and shiny as it could be. Bloat is not a pretty word so I'll refrain from using it.
Excel and Word get new ribbons for their hair in their upcoming version 12, but Project for the most part has to be content sweeping out the fireplaces of enterprise while the others are at the ball. One almost wishes that one could wave a wand and convert the resource substitution wizard into a golden full fledged resource leveling engine with a team of dalmations running along behind or that the tired old gui could be cleaned of soot. But I fear it is not likely, and even if by some miracle Project were cleaned and polished at the end of the evening someone will shut down the program without saving leaving only a spool file blinking in the task tray.
No, dreams are not practical. The best approach is to jump into the swamp with project anyway. You can kiss it if you want, but it won't turn into a princess. Not that you would want it too. It is a pretty useful as a frog as it is.
Posted by Jack at 03:43 PM | Comments (3) | TrackBack
Good ol' rock
There is a Simpson's episode when Bart is confronted with a game of Rock, Paper Scissors (AKA: Jan Ken Poi, ro sham bo ...) and thinks to himself "Good ol' rock". Meanwhile his opponent is thinking "poor Bart, always chooses rock". So what does this have to do with Project Management? Nothing, except that often people go to what they are familiar with, to what they are told is going to be a winning solution or what they have won with in the past. Of course, what makes it funny is that Bart continues even though his choice loses constantly - he is attached to it for some magic reason.
Maybe it is not so much a stretch to think this is true of other people too. I can imagine some people thinking "Good ol' PMBOK" while they pull their copy off the shelf. Of course, going with what you know or what has worked in the past is a very common thing to do. If the situation is truly the same, then the solution that worked in the past should continue to work.
But sometimes the situation is somewhat misleading. Sometimes it looks the same on the surface but is different underneath. Greenland is an example. When the Norse first arrived there it looked on the surface that it was a fertile place on par with their native lands, but over time it was found that the soil was not the same glacial deposits of home and was instead a thin covering and did not have the same fertility and capacity for sustaining agriculture that their homelands did. Of course their solution for survival was the same sort of pastoralism which worked back home and eventually it ended up failing them and they disappeared from the island. Oops... should have taken up whale hunting...
One approach to dealing with the limitations of rocks is to continue to improve or polish them. The Stone axe was a mainstay of many cultures. It was refined in shape and material to be a very useful tool. Yet now it is merely a curiousity in most cultures. Somehow people switched over to something different and better and now we make axes out of steel. Quite an advancement one would say. We can use our technology to make something perform better. We see this line of thought in some project management tools. We add new features or take advantage of new technologies - a better database, better networking, faster machines etc.
But it totally ignores one thing - that is that an axe is not that great for fishing. Sometimes the situation seems like the problem is something an axe may be useful for, but a closer or more insightful look might find that a fishhook is called for if the solution is something which is sustainable.
I guess the point of this is to convince myself that even the most polished rock is not enough. A bag of rocks may be even better, but better than that is time to really assess the situation and a bag of diverse tools from which to draw from, tools which might fit the situation better than good ol' rock.
Posted by Jack at 09:25 AM | Comments (0) | TrackBack
January 30, 2006
What does done look like?
I often see this posed as a clarifying question when people are discussing project milestones. In fact, I just saw it this morning as the results of a google search for it led some unsuspecting reader to my blog for an answer. Fortunately google knows all and tells all so I'm happy to pass it along:
"What does "done" look like, you ask? It's when the hot dogs start turning real deep red, and may start having bubbles form on them. They might also crack" Source:http://jweisz.org/food/mac_n_cheese.html
I don't know how you can do any better than that.
Posted by Jack at 09:41 AM | Comments (0) | TrackBack
January 27, 2006
Japanese Beer Pouring Machine
Alice has pictures and description of a Japanese beer pouring machine up on her site. Apparently it was a bright spot during the recent Narita Airport shutdown which left thousands of JAL customers stranded.
"Just as the glass is about to get full, the machine tilts one more time. This time, foam comes out of the right spout, and voila~! A perfectly poured glass of beer with a lusciously enticing foamy head!"
Posted by Jack at 07:33 AM | Comments (0) | TrackBack
January 26, 2006
More Microsoft Project 12 features popping up
New MS Project 2006 features revealed at Project Conference held last week are making their way through the web. Bill Raymond posted a list of the top 10 on his blog here: MPA Blog. I'm interested to see that the first item:
- Client:
- Project Professional has some nice scheduling enhancements, but the client will remain mostly the same as Project 2003.
is really not a feature at all, but a recognition of the relative lack of any new features. Of course there is one greatly anticipated feature on the client and that is multi-level undo which people have been asking for for more than a decade. The rest of the features on Bill's list are all related to Project Server in one way or another.
This isn't that surprising though since the audience at the conference (according to Larry Duff's blog) was overwhelmingly people who make their living from Project Server. The ordinary desktop user doesn't spend money to go to a multi-day conference about project. Indeed, since the release of Project 1998 they can mostly make due with the skills they have as not much has fundamentally changed. I suppose there must be some who advocate for the single user with a single copy of project, but they are few and scattered and do not seem to have Microsoft's ear. I am somewhat concerned that the overwhelming feedback that Microsoft gets from those with an economic stake in developing and selling solutions based on Microsoft Project is what is setting the direction for future innovation (or in the case of the client, the lack thereof). More than once I've seen consultants grin sheepishly when I have referred to Project Server as "the Consultant's Full-Employment Act".
Of course to counter my argument is this example from the "I hate MS Project" crowd titled "why-ms-project-sucks-for-software" which seems to point that Microsoft has the right priorities - only he doesn't know it yet. Some of his concerns - particularly those of integration with other software development tools are on Microsoft's radar and are being addressed... the only issue being that it requires a suite of MS software rather than the diverse collection of tools he lists.
Maybe the average user does want a highly complex, integrated solution which requires extensive infrastructure? Or then again, maybe not.
Posted by Jack at 12:11 PM | Comments (2) | TrackBack
January 24, 2006
PMI Obfuscation and the PMBOK
PMI keeps a very tight control on the PMBOK(c). I've already mentioned that there is no such thing as a free PMBOK download, at least for several years. This is understandable as it is probably one of their key sources of income and only an idiot would give their works away for free... Um... oh, yeah, I have ads. Clickety click.
But, as Glen has pointed out while PMI is controlling access into the PMBOK, they are also controlling access OUT of the PMBOK. He lists the 5 items referenced by the PMBOK: "A dictionary, two ISO standards, a PMI Journal Paper and a Handbook.". For something billed as "A Guide to the Project Management Body of Knowledge" it appears very thin on the guiding part. Indeed, in an academic setting it would be rejected as being under-researched. How does PMI support the claims implicit in the PMBOK? A cynic might say that they are just making things up. Of course I am not THAT cynical. I know that this stuff came from somewhere and that books and papers (as well as experience) are the actual "Body of Knowledge" so that is why it seems so strange.
Is it to avoid a conflict of interest and to escape from charges of favoritism? Or is it that they want no one to leave the island of information under their control? Anybody know the reason?
Posted by Jack at 10:42 AM | Comments (2) | TrackBack
January 23, 2006
One good thing about Project 2006 (AKA Project 12)
Jensen Harris says personalized menus are going away.
You might know what these are but not what they are called. They are the menus which show "recently used commands" first and hide the entire rest of the menu. To me this was about as stupid as a real menu (one from which you pick food to eat) which only showed you what you had the last time you were there.
Microsoft put them into Office (including Project) as an attempt to hide the clutter that feature bloat had caused. Unfortunately beyond limiting your perspective to things you already knew - thereby limiting your growth and understanding of the application, they had the unfortunate property of changing occasionally so you could not rely on a consistant physical location for the menu item. Jensen wrote a bit about this before stating:
"Auto-customization, unless it does a perfect job, is usually worse than no customization at all. Although the algorithm used to promote and demote menu items is rather complex and well thought-out, it's not perfect. Because it's not perfect, it does the wrong thing a lot of the time. (If it's even clear what a "right thing" is for a feature like this.) What people experienced is a sense randomness and unpredictability: one time, a menu item would be in a certain place, and then two days later it wasn't there anymore."
Well, he definitely got that part right. And it is good news that even though MS Project 2006 is not getting the same sort of interface makeover that the core office apps (Word, Excel, Powerpoint) at least this feature will be off by default.
Posted by Jack at 03:42 PM | Comments (0) | TrackBack
Self Image and Economic Propaganda
Some people will go to great lengths to justify their lifestyle. An example is Michael S. Rosenwald who writes for the Washington Post. In his recent article "Why America Has to Be Fat" he writes:
"Being fat makes me a lot of things -- a top contender for type II diabetes, for instance, or a heart attack, or stroke, maybe even a replacement knee or hip...But in many ways, my being fat also makes me pretty good for the economy. ... An efficient economy produces sluggish, inefficient bodies."
I find it a bit odd that he is claiming both that his being fat is both good for the economy and at the same time is produced by the economy. A virtuous circle if ever there was one. This clever piece of rationalization relies on some "science" from Tomas J. Philipson who studies obesity at Univ. of Chicago and who states:
"The obesity problem is really a side effect of things that are good for the economy. But we would rather take improvements in technology and agriculture than go back to the way we lived in the 1950s when everyone was thin. Nobody wants to sweat at work for 10 hours a day and be poor. Yes, you're obese, but you have a life that is much more comfortable."
To begin with, the correspondence between being poor and thin bears some investigation. In fact it contradicts evidence which shows that poorer people in the US are not necessarily thinner, and this is due to their diets which are heavy with fats and carbohydrates. Indeed "fat" food is cheap food and a strong economy and wealthy citizens allow the choice of healthier (and sometimes more expensive) foods rather than the reverse.
It seems odd to me that what might be reasonably considered a drain on the economy (currently $124.7 billion for medical treatments related to obesity) is being extolled as a virtue. In a world where writers like this have no notion of cause and effect and are incapable of what seem to me to be the basics of logical thinking I despair about the future. One wonders if the next article will be one extolling the glorious economic value of cancer to our medical industries.
Posted by Jack at 11:30 AM | Comments (0) | TrackBack
January 20, 2006
PMP Study Guides
Carl Stumph offers up some useful PMP study materials on his site here:
Project Management Professional - PMP - Study Group
Interesting to see the cease and desist letter he received for posting the PMBOK for free downloads and their request that he turn over his domain name to them. Your PMI $ at work I guess :-)
Posted by Jack at 04:09 PM | Comments (0) | TrackBack
January 19, 2006
Waxing Aphoristic
Tongue Twisting:
"In the land of anecdotes the fork-tongued man is king" - me, 2006
Mmmmmm Bacon:
"Silence is the virtue of fools"
"Reading maketh a full man, conference a ready man, and writing an exact man."
" Ipsa Scientia Potestas Est (knowledge is power)"
Francis Bacon 1561-1627
Just goes to show you what he knows.
Posted by Jack at 09:55 PM | Comments (0) | TrackBack
January 18, 2006
Feedback
Sorry but I'm disabling Tr_ckbacks as I'm getting up to a thousand bogus ones every day. If you really want one, leave a comment.
Posted by Jack at 02:36 PM | Comments (0) | TrackBack
Evidence Based Management
Found this excerpt from Harvard business review which ties in to my recent "management science" post that many project management myths could use a bit of investigation and confirmation:
Noise Filter: If medicine is the goose, could management be the gander?
A short excerpt of the excerpt:
"Stories are more persuasive, anyway. It's hard to remain devoted to the task of building bulletproof, evidence-based cases for action when it's clear that good storytelling often carries the day."
Posted by Jack at 02:23 PM | Comments (0) | TrackBack
January 17, 2006
More on how NOT to skip NOT blank tasks in MS Project Macros
Clayton Scott read my post on skipping blank lines (also known as blank tasks) in project by using the statement
If Not Task is Nothing Then...
He suggested that rather than using a negative that we use:
If Task is Nothing Then
Next Task
End If
but the problem is that the Next Task within the If..Then statement is not recognized correctly by the compiler and the code won't compile. Clayton's intent was to simplify the code and remove the confusing Not from the statement. I think it is possible to remove the Not but this would require implementing a counter of some sort or using Onerror, both of which would not lead to greater simplicity.
So it looks that for the time being we are stuck with using If Not Task is Nothing.
I'd like to say thanks to Clayton for trying to point out possible improvements though. Comments are always welcomed.
Posted by Jack at 10:13 AM | Comments (0) | TrackBack
January 16, 2006
Management "Science" and the PMBOK
Among a segment of the population the PMBOK has a bad name for a number of reasons (some content related, others regarding the organization surrounding it) but it does have one thing going for it and that is in the reduction of confusion. Prior to the PMBOK the acceptance of a common taxonomy across Project Management was spotty. Certainly there was strong development of many principles and techniques, but they were spread pretty widely. The PBMOK changed that.
Now, I certainly don't agree with the way that the PMBOK is often taken as a bible and think that it is detrimental to those who treat it that way, but as Francis Bacon wrote some 500 years ago in the famous aphorism:
"Truth emerges more readily from error than from confusion"
It would seem that to find some truth, an incomplete and perhaps wrong statement of where we are is a better starting point than a broad selection of conflicting schools of thought.
Indeed the current situation still looks a bit to me like what Thomas Kuhn described as "early fact-gathering, a state of affairs where
"all of the facts that could possibly pertain to the development of a given science are likely to seem equally relevant. As a result, early fact-gathering is a far more nearly random activity than the one that subsequent scientific development makes familiar. Furthermore, in the absence of a reason for seeking some particular form of more recondite information, early fact-gathering is usually restricted to the wealth of data that lie ready to hand"
A recent post to the agile management mailing list where-in the author was searching Google for evidence to support his argument seems to place us firmly in the early fact-gathering era. The reason being that real "Science" is hard and expensive and in the absence of a clear need to do it (to defend one's practices or to remedy an error) it just doesn't get done. In the current world anecdote is enough. Some measure of charisma and perhaps a high Google page-rank helps as well.
However, the PMBOK is not enough yet. What PMI should be doing if they want to advance the knowledge of Project Management further is to commission some experiments to validate the claims which are implicit in the PMBOK. Rather than footnoting (if they even do that) conflicting schools of thought, they should mount an active challenge and seek to design experiments which validate - or invalidate - the positions that are implicit in their categorization of "best" practices. Until they do that we are still picking up facts where they lie, searching Google for anecdote, conjecture and opinion.
Some one please pass the phlogiston...
Posted by Jack at 08:46 AM | Comments (1) | TrackBack
January 12, 2006
Momma don't take my kodachrome
It says here that Nikon is exiting their film camera business except for the F6 and FM10. I'm surprised it came so soon.
Link to press release: http://www.nikon.co.uk/press_room/releases/show.aspx?rid=201
With 35mm film no longer being the key factor in setting format size I am wondering what shapes the new cameras and lenses will take. My guess is they get slightly smaller (means lighter, cheaper)
Posted by Jack at 01:47 PM | Comments (0) | TrackBack
They aren't flying yet though
Seems that Taiwanese have created pigs which glow green. Jellyfish genetic material has been spliced into their genes. See the story and a couple of pictures here: http://news.bbc.co.uk/1/hi/world/asia-pacific/4605202.stm
Just wait until Sam hears about this.
Posted by Jack at 12:55 PM | Comments (0) | TrackBack
January 03, 2006
The Schedule as a Symptom
The more I think about it the more I am convinced that many people see the schedule as the problem rather than a symptom of some other problem. Schedules even in the best case are an abstraction of the work to be done. They delineate the work to be done and place it in chronological order with some notion of the relationships between tasks and resources required. There is always some art involved in this representation and while some lovingly craft a beautiful still-life others are fingerpainting or making sketches or perhaps even painting by number. But in this process they sometimes forget that the progress of the project is actually being achieved by people/things doing things. And for a large part, schedule "problems" are a result of the problems with those activities.
I'm sure that most people know this, just the same as they know their speedometer is a good measure of engine health only when it drops far below where it should be, but at that point most of the damage has been done. My point isn't that you should ignore schedules, but rather that some other, more immediate measure should also be used to understand how healthy your progress is. If you are not using those sorts of objective measures to drive the schedule you may be too abstracted from the actual work.
Posted by Jack at 01:32 PM | Comments (1) | TrackBack
