Project

I'm interested if anyone else does something similar and if so, what are the specifics of their method. Post a comment or a link if you have one.

In a related note, we were recently looking for some information from other projects. In searching out the post-mortems for other projects my co-worker asked his contacts to "Send me the first draft". The reason being that as the presentation got reviewed and refined by different layers of management it became less useful in understanding what the real issues were.

Posted by Jack at 08:16 AM | Comments (1) | TrackBack

May 24, 2005

Real Estate Bubble 4

Dan Gillmor writes:

Just about everyone in the pictures is smiling. Perhaps this is truly reflective of the current reality. After all, speculation is being rewarded at the moment, as people buy and flip homes and land the way the day traders were buying and flipping stocks in 1999.

After this bubble deflates, I hope Fortune comes back with a cover story that shows how people feel when they lose everything.

It certainly smells like a bubble to me.

Posted by Jack at 10:46 AM | Comments (0) | TrackBack

If you think I'm criticizing you...

"One seeks a midwife for his thoughts, another someone to whom he can be a midwife: thus originates a good conversation"
F. Nietzsche

Posted by Jack at 06:44 AM | Comments (0) | TrackBack

May 23, 2005

An American Invention

This is old news, but then again sometimes it is good to read the classics. Geert Hofstede starts off his article on Cultural constraints in management theories with the sentence: "Management as the word is presently used is an American invention."

It is certainly worth looking at if you work across multiple timelines and borders. And it certainly argues against the concepts of "one size fits all" and "one size to sell" which are common among consultants.

Posted by Jack at 12:59 PM | Comments (0) | TrackBack

More Sweetness and Simplification

I wrote earlier about the propensity of Project Management types to adopt checklists to explain and (I assume) inspire themselves. I keep finding new examples. Am I just convincing myself that it is more common then it really is? I still can't put my finger on what it is about this kind of writing that annoys me. I don't think it is wrong, but it does seem that something is missing. Maybe it is just because they are prescriptive - "do this" - yet offer no reasoning for why the rules should be followed.

A rule is a generalized response to a certain situation or problem. I find it more interesting to read about the problem and the solution rather than some rule which may or may not apply. The only exception is "thou shall not link to summary tasks" the reasons for which should be obvious to all and the penalty for transgression is nothing but sure and swift.

I guess I'm just a "spirit of the law" rather than a "letter of the law" person at heart.

Posted by Jack at 12:14 PM | Comments (5) | TrackBack

May 21, 2005

PMBOK Good - PMP Bad - PMI ???

I first came in contact with the Guide to the PMBOK nearly 10 years ago. It used to come free on a CD with every copy of Primavera and you could download it off the internet. At the time I thought, great, this is a very useful taxonomy of project management practices. I think it was instrumental in defining common terms which if used consistantly would allow people to discuss and think about project management without misunderstanding.

As PMI matured, the PMBOK got updated and went under more control. Rather than a free disk in every box of software or something anyone could download it became a document that came with a paid membership. You can access certain excerpts of it on-line after filling in some form and agreeing to terms and conditions (PMI site here) but the open attitude and ability to pass the disk around to whoever wanted it is gone.

I seem to recall political battles around the turn of the millenium as well regarding what would go in and what would stay out. I didn't pay enough attention to remember what happened so I won't cover that here, but I'm quite certain that the battles began. Next thing I know the PMBOK became a reference text for PMP certification and a cottage industry of PMP exam trainers sprung up. All of this has a cost. PMI membership has a cost. PMP certification has a cost. Training can cost a couple thousand dollars. And then there is continuing education...something provided by PMP approved consultants.

The organization that once encouraged free sharing of project management ideas and defining common terms so we can engage in productive discussion (see the discussion/argument about what Enterprise Project Management means at Brian's Blog) and debate seems to have turned into a commercial enterprise. A look at the meeting minutes from the last Board of Directors meeting (held in Singapore Feb'05) shows just two items: approval of a travel policy for directors and the following notes about PMP certification:

• PMI will remain the global leader in project and program management credentialing driven by market demand, stakeholder needs and advancement of the profession.
• PMI’s credentialing activities will give priority to cooperation over competition while ensuring that competitive activities are undertaken in a fair and ethical manner.
• PMI will maintain standardized credentialing practices globally and drive innovative solutions which address regional and local stakeholders’ needs.
• PMI will expand the levels and types of credentials and position them to meet the demands of the marketplace. PMI will explore new possibilities for innovative and defensible methods of assessment which are scalable and portable.
• PMI will develop and maintain a clear value proposition for all credentials.

If I use the technique of stripping out the adjectives (very useful when reading corporate speak) and do a little clean up the message reads: "Expand and dominate the market for Project management credentials". Is this to pay for travel to Singapore? How does this benefit the membership at large? Is credentialing the functional equivalent of the sale of Girl Scout Cookies - something to raise money so that PMI can do good deeds? If so, then where are the good deeds discussed?

Sorry PMI - you leave a bad impression when all you do is look for and talk about money.

Posted by Jack at 11:22 AM | Comments (1) | TrackBack

May 20, 2005

Critical Resources

I keep losing track of these things so I'm going to just put all the links here:

Project 2003 Object Model

Project 2003 XML Schema

Building a Project Server PDS Extension with dot net.

PDS Reference download

I used to have a link to the code for the "Export Timescaled Data to Excel" add-in, but I can't find it right now.

[Update: Here it is Download Timescaled Data Source Code]

Any of these links lead you to the MSDN documentation. I suggest you browse around the other topics while you are there.

Posted by Jack at 03:24 PM | Comments (0) | TrackBack

May 19, 2005

Automating Project Management Processes is Very Dangerous

I've been telling people that the reason that I am fundamentally opposed to tools like Microsoft Project Server is that it does not adequately convey the details of a project. It does not allow for project knowledge to be conveyed. It is great for project accounting, but less so for the active management of the process. For a long time I've been alone in this view. But now Glen Alleman writes that a veteran project manager told him that there are:

two critical attributes of a successful project

1. Have the right people - this means hand picking them
2. Manage the interfaces - this means pay close attention to the send and receive points of the project. Do this "manually" through face to face interaction.

Glen's conclusion - automating project management processes is very dangerous. Nice to know I'm not alone. Face to face interaction reinforces commitment. Face to face interaction brings out latent issues and nagging doubts before they impact the project. Face to face interaction is a fat pipe compared to the thin straw of a web interface. I feel it is a necessary part of the project management process.

Posted by Jack at 12:45 PM | Comments (2) | TrackBack

"the long arm of privilege and power picking their pockets"

Even if you don't like pledge breaks and cooking shows, this is well worth reading. Bill Moyers' speech to the National Conference for Media Reform

Posted by Jack at 12:39 PM | Comments (0) | TrackBack

May 18, 2005

A bug by any other name...

Johanna Rothman usually gets things right (I've posted earlier about her excellent series on "schedule games"), but her recent post about not calling bugs bugs points out an unfortunate tendency in Management Consultants. She suggests to her client that he should "change his naming of "bug" to "defect."' on the premise that bugs are defects and that people do not take responsibility for bugs. She seems to be making the point that people would actually confuse them with real bugs which we all know are incredibly difficult to train and even the best of them refuse to clean up after themselves. And that once we are confused about them we start thinking that they came in through the windows. (OK, so yeah, windows does have bugs).

So how is this unfortunate? Well, most developers know what a bug is. Most testers know what a bug is. I've never seen anyone confuse a "bug" with a cockroach much less an african millipede. Now, in my mind a defect is something which is more ambiguous than a bug is. What is the root cause of the defect? How do you fix it? Did a person cause it or is it something that happened in transit? Sometimes defective things are actually broken by the user. It is foolish to throw away a perfectly usable and well understood term like bug and use an ambiguous term like defect in its place. It is unfortunate because consultants try to clear the air but instead end up with a swarming mass of words which annoy the people who are just trying to get their work done.

Spraying the air with buzzwords does very little to clear the air of bugs.

A hint to Johanna: Bug - 3 letters 1 syllable, Defect - 6 letters 2 syllables. Imagine the saving of powerpoint space alone!

PS: For those who are unclear of the difference between bugs and bugs here is a quick primer on the African Millipede courtesy of the San Francisco Zoo:

The giant African millipedes can grow to be 12 inches long. For every body segment, the millipede has two pairs of legs, so they give the appearance of having hundreds of legs. When born, they only have three pairs of legs, and as they grow, they increase in size and add segments with each molt. In order to grow, they must go through a series of molts which can be dangerous. Before going into molt, the millipede must find a safe place to hide, because during this time, they are vulnerable to attack. All together, millipedes spent about 10% of their lives in molts. Some millipedes do not have eyes, but all have antennae and jaws to chew on plants. When threatened, they can excrete a foul-tasting and smelling fluid from specialized stink glands. Their main line of defense is to coil into a tight ball.

The giant African millipede can live up to seven years.

Hmmm... so maybe they aren't so different afterall.

Posted by Jack at 05:49 PM | Comments (0) | TrackBack

Real Estate Bubble 3

Stephen Roach from Morgan Stanley writes:

I continue to be struck by the eerie similarities between post-bubble patterns in Japan and America. Five years after the bursting of the US equity bubble, the Nasdaq continues to track the post-bubble Nikkei very closely. Is this merely a coincidence or, in fact, a visible manifestation of the long and drawn out perils of a post-bubble shakeout? ... Everyone -- from investors and recovering dotcomers to policymakers and politicians -- seems united in their conviction to dismiss this possibility as nothing short of blasphemy."

I've seen the mania around me. I'm wondering about how those who are using low APR adjustable rate mortgages could cope with interest rates of 8 or 10%. The rest of the article is definitely worth reading.

Posted by Jack at 06:01 AM | Comments (0) | TrackBack

May 17, 2005

Bubble 2

"Strong demand and low interest rates through the early spring helped push the median price for a single-family home in the nine (SF Bay Area) counties to $622,000, according to the monthly study by DataQuick. That was 3 percent higher than the previous record of $605,000 set in March and 19.6 percent higher than one year ago." Source: www.sfgate.com

Hmmm...

Robert Kleinhenz, economist at the California Association of Realtors says this isn't a problem because low inventories will keep prices up. It is also a "foregone conclusion" that prices will go up. Where is he an economist again?

Meanwhile new buyers are facing average mortage payments of $2,659 a month. I'm wondering what the economists from The California Association of Mortgage Brokers are saying about this.

Posted by Jack at 09:53 PM | Comments (0) | TrackBack

May 16, 2005

Not clear on the concept

Ebay has one of the largest collection of idiots on the planet.

Posted by Jack at 09:16 PM | Comments (1) | TrackBack

Getting off the ground

Eric Hedman writes about the failed DART mission and gives a few examples of what causes projects to succeed or fail. The key factors he cites are choosing projects with a real chance for success, avoiding scope creep and having a project which people will support.

Posted by Jack at 12:29 PM | Comments (0) | TrackBack

Theory of Constraints (TOC) Reference Site

For those reading my entries on TOC and wondering what it is I am talking about, here is one of the more useful references on the Theory of Constraints. I think it does a great job of laying out the principles, thoughts and history behind it. The author does at times get carried away with jargon and uses phrases like "verbalizing intuition" for example. But if you like hot talk like:

The reductionist/local optima approach is well represented; firstly by the family of material requirements planning (mrp), manufacturing resource planning (MRP II) and enterprise-wide planning (EPR). Secondly, it is represented by “reversions” from more systemic but nevertheless transitional approaches. The reversions are World Class Manufacturing and Lean Production.

The transitional class is composed of the Ford Production System and the Toyota Production System. Both methodologies are mass production systems and while both are paced or synchronized to the slowest step in the line, safety is distributed evenly throughout the system. The advancement of the Toyota system over the Ford system is that although safety is spread throughout both, the Toyota system seeks to substantially reduce it by increased quality throughout the process.

Posted by Jack at 07:11 AM | Comments (0) | TrackBack

May 14, 2005

Aftermath

Like Piranesi I've always been interested in ruins but the only ruins around here were the ww2 gun emplacements on the headlands. Even the Falstaff brewery (infamous in the early 80's as "the Vats" - a squatter colony) has been converted into office space. So I can only look on in amazement at the variety and scope of modern day ruins in Japan - the result of their bubble economy. The site is in Japanese, but does not need much explanation. Almost every photo series tells the story of a failed attempt at fun and enjoyment. Link: http://home.f01.itscom.net/spiral/research.html

Posted by Jack at 09:38 PM | Comments (0) | TrackBack

May 13, 2005

Recursion in Project VBA

The Fifth in a Series of Short Notes about Using Project VBA
Recursion is a programming techique which is similar to the process of taking a video of your television when the television is displaying the video output of your video camera. The result - an endless tunnel of pictures of your television.

So how can this be useful in programming, and more specifically in programming Microsoft Project? Well, recursion is also well suited for dealing with parent/child relationships or dependencies, both of which are essential parts of Project. Recursion allows you to easily get the subtasks of the subtasks of the subtask of a task and because it continues indefinitely (or until it hits a limit) it will get to the last task in the project without you having to keep track of how many levels deep it needs to go.

It can be difficult to grasp the concept without a concrete example so let's start with one right away and explain the details as we go along. Let's say that you have a number of tasks which may be viewed individually (perhaps in project server) and they will no longer show the heirarchy which is in the file. Some may even have the same name as each other, just like you can have two John's who are unrelated and different. The solution to this confusion is to use a text field to show the entire path to the task. That path is made up of all the names of the parent tasks of the individual task.

One way to do this is brute force:

Dim mytask As Task
Dim myoutlinelevel As Integer
myoutlinelevel = 1
While myoutlinelevel < 10
For Each mytask In ActiveProject.Tasks
If Not (mytask Is Nothing) Then
If mytask.OutlineLevel = myoutlinelevel Then
mytask.Text2 = mytask.OutlineParent.Text2 & " | " & mytask.Name
End If
End If
Next mytask
myoutlinelevel = myoutlinelevel + 1
Wend
End Sub

The trouble with this approach is that it runs through the entire set of tasks one time for each level of heirarchy that you want to name. And, you have to define how many levels deep you want to go. Even if you have only one level of heirarchy this code will still read and check each task 10 times. And if you have more than 10 levels, the tasks beyond the 10th level will not get labeled correctly.

The solution is to use recursion. With recursion we ask the program to name all the children of a task and then name all the children of that task all the way down until there are no more children. We do this by having a procedure which calls itself. Here we are using a procedure called "kids" which calls the same procedure for all of the child tasks - when it runs using those child tasks it will get all their child tasks etc. etc. etc.

Sub kids(ByRef t As Task)
Dim kid As Task
t.Text2 = t.OutlineParent.Text2 & " | " & t.Name
For Each kid In t.OutlineChildren
kids kid
Next kid
End Sub

Pretty simple. Now the only question is how to get it started off. We can't put the code to start it inside the procedure or it will keep restarting itself. So we write a procedure which sets the starting task and then calls the kids procedure:

Sub recursionExample()
Dim t As Task
Set t = ActiveSelection.Tasks(1)
kids t
End Sub

Sub kids(ByRef t As Task)
Dim kid As Task
t.Text2 = t.OutlineParent.Text2 & "-" & t.Name
For Each kid In t.OutlineChildren
kids kid
Next kid
End Sub


That is all there is to it. I have an example of how recursive techniques can be used to trace dependencies on my website which adds some additional logic so it can trace forward or backward or only critical tasks, but the basic principle is the same.

One thing to be aware of before you use recursion is that whatever you are recursing through does require some limit or stopping point. In this case it stops when there are no further children. In the Trace macro it stops at the end of the chain of dependencies. However, if you are not careful you can construct something that will continue indefinitely. To avoid this, try setting a breakpoint so you can step through the code the first few times to make sure it doesn't break. And always back up your files before you start.

Posted by Jack at 10:57 PM | Comments (0) | TrackBack

This is not going to fit in the minivan...

I think it will take several trips to bring the latest product from IKEA home. Where did I put that hex key?

Posted by Jack at 06:33 PM | Comments (0) | TrackBack

Real Estate Bubble

I'm collecting some links on what many people think is a real estate bubble. It is hard not to think that there might be a bubble when housing prices in my neighborhood are topping US$1,200,000 for a two bedroom house. Of course it is nice to think that it is not a bubble and that my house is making me more money than my job is, but really, how can that be?

My starting place for links is the Mises Economics Blog.

Posted by Jack at 12:07 PM | Comments (2) | TrackBack

$... Euro...?...

We have seen the (long and often painful) economic "unification" of Europe come to pass. Now there are the first signs of a similar unification happening in Asia. It will be interesting to see how this plays out in the coming decades...

Posted by Jack at 07:37 AM | Comments (0) | TrackBack

May 12, 2005

Any Construction Managers Reading This?

It seems like everything on the internet which is project management related is either software or tech development. Leave a comment or send me an email if you are interested in construction management.

Posted by Jack at 10:58 PM | Comments (2) | TrackBack

Should I be worried?

Google seems to know everything so I'm a bit concerned that the Google ads on my recent post are all about Paranoid schizophrenia:

A voice in my head is telling me not to worry about it though.

Posted by Jack at 01:11 PM | Comments (0) | TrackBack

Stuck in a grey cubicle?

Well, now there is no need to leave. If you are like me and always want a window seat in the airplane so you can look down at the world then googlesightseeing.com is the site for you. Selected aerial photographs from Google's mapping application.

Posted by Jack at 12:33 PM | Comments (0) | TrackBack

Electronics Industry Standing Up?

Junko Yoshida has an article in EETimes covering vertical vs. horizontal integration. It is a question of control vs. economy of scale and proponents of the vertical approach claim that vertical integration allows them to be more responsive to customer requirements and allows them to differentiate their products. In parallel with these discussions and prognostications, Intel continues with its new "Platform" strategy which, in my opinion, tries to turn what has been a horizontal business for many years into one which almost walks upright.

There are some interesting parallels for Project Management where a PMO is a horizontal model and embedded Project/Program/Platform management is the vertical model. How do PM tools and processes support these different models? Lots to think about...

Posted by Jack at 12:12 PM | Comments (0) | TrackBack

May 11, 2005

Project 2006

If Bill Gates' comments about Office 12 are correct, then we can expect that the next version of Project will be Project 2006 (or whatever naming scheme they have dreamed up by then) rather than Project 2005.

Of course Project has not always been in lock step with the rest of office, so it is always possible that Project will ship earlier, but it is dependent on Office for a lot of the UI.

Posted by Jack at 05:05 PM | Comments (0) | TrackBack

Art, Science or ...?

I used to have a t-shirt that I got from Primavera. It had an illustration of a artist, a scientist and a large bull. The caption was "Project Management - Art, Science or ...? If nothing else it was an acknowledgement that Project Management is at best an amalgam of the three. It is left as an exercise for the reader to determine the relative proportions in any particular "theory" or approach. Coming from a design background I can't help but recommend this article in Design Observer on the same topic.

Posted by Jack at 12:56 PM | Comments (0) | TrackBack

MS Project Examples

Added a new example covering grouping and conditional formatting in Project to my website. From my log it seems that examples are a popular topic.

Posted by Jack at 07:02 AM | Comments (0) | TrackBack

May 10, 2005

Oscilloscopes

In response to my post on Project users Joël from Go-Project noted that he would not curse at an oscilloscope which he did not take the time to learn. It is a good point. With all of the different features and modes, project is probably as complicated yet people want to plug it in and have it work. And like an oscilloscope, the function of project is to measure and monitor rather than to perform any work itself. That is to say that Joel can't use an oscilloscope because he is not an electrical engineer. In the same way, those people cursing at Project are a few steps short of being Project managers.

He goes a bit further and accusing me of ranting about Project server (what ME rant!) but it still isn't convincing Joel. Different situations call for different tools and different processes. I'll grant that Project Server is the tool for when you want to do Project Accounting, but I'm still not convinced it is necessary for certain other types of projects.

Anyway, I think we can both agree that Joel is right. Understanding the tool is necessary for proper use.

And if you are one of those frustrated project managers, often the answer is to just ask for help. Try asking here.

Posted by Jack at 10:41 PM | Comments (0) | TrackBack

May 09, 2005

The Bigger They Come

If you are reading this with Firefox take a minute or two to disable Javascript at least until you read this warning from Mozilla.

Here is how:

Seems like with fame and fortune come the need to deal with forces trying to take you down.

Posted by Jack at 05:58 PM | Comments (0) | TrackBack

Project Users

Microsoft Project users are not always a happy bunch. It often seems like they come across it by accident:

microsoft project got no idea what the hell is that... only know i need to master it when boss is back... hiazz... dunno can find pirated copy of it anot... den can at least try abit at home mahz... this IA learn so many software... haha... should be of use bah... next time.. haha

That is all. :-)

Posted by Jack at 05:20 PM | Comments (4) | TrackBack

Project Examples Act I

You probably arrived here because you are looking for some Microsoft Project examples. You are in the right place, but you are looking for the wrong thing. It is the right place because I have some ideas which may help you to develop a solid project plan. You are looking for the wrong thing because each project is at least partly unique and so are the people who are involved in those projects.

Project Scheduling and the Bard

Shakespeare would be disgusted to hear that I could compare a project schedule to something like King Lear. And indeed there are a number of projects which end up looking more like Waiting for Godot. It is unlikely that your schedule has the intrigue or audience appeal (unless perhaps it is Steve Batt's infamous "Purple Schedule") But the basic idea is actually rather similar.

The first task is in developing the plot. In a project schedule getting to the finished project is usually sufficient to warrant some applause, unless it has taken so long that the audience has gone home. The point here is that you need to be very clear about what it is you are undertaking and what you hope to achieve before you start working out the schedule. Defining the scope of the project is what you are after here. It must be clear to everyone involved what that goal is. The schedule you are going to put together is not going to help much if people have different interpretations about what the work is. I'd suggest that each of the major milestones along the way are also documented and more importantly discussed so that they are clear and well understood. You can modify them along the way if you need to, but unless you have the key team members in agreement and understanding about them, you will truly get nowhere.

Five Acts

Once the goals of the project are set, we can take another lesson from the stage. It is rare, and painful to sit through a single act which stretches over a couple of hours. Attention is stretched to a breaking point and it becomes difficult to understand the entire thing. So, since the time of the Greeks tragedies have been structured with 5 acts. There is no inherent limit to the phases in a project, but it is useful to have at least one major milestone periodically so that progress can be measured and more importantly as a near term goal for the people working on the project. And when they meet that goal it is time to call out the chorus and celebrate a bit.

So what sort of plan would you have at this point if you entered it into project? Actually a quite sparse one. Just a handful of milestones, but doing this work before you set into building the schedule will help you avoid problems later. The schedule is more than just a tool to account for the time spent on the project. It is a tool for communicating the plan to people who are executing the plan and to the people who are responsible for managing it. It must be clear and logical.

One of the benefits of breaking it down into phases is that working out the details of each phase is an easier task than doing the whole thing at once. Additionally, you can use a technique called "rolling wave planning" in which the near term activities are highly detailed while those later in the project (and which you may have much less visibility into) can be less detailed. As you near the end of a phase, the schedule for the upcoming phase is refined further as you gain higher certainty about it.

Plagarism

Now that you have the phases mapped out (including what you are actually going to produce or accomplish in each phase) it would seem like an example project would be helpful. You could just paste in a generic flow that you copied from somewhere. And of course you could. But there are a number of reasons not to do this. The first is that except for highly repetitive projects, there are usually some peculiarities about certain elements of the work, or site conditions that need to be taken into account, or people or materials which are not completely interchangeable. Furthermore, if you are working off of an example from somewhere you have no idea of what sorts of assumptions about productivity or dependencies were made by the original author. This is why I say that example projects are largely useless. On top of that, there is a level of understanding of the work that comes from putting the plan together. This building of a mental model and testing your assumptions gives YOU an understanding of the project which is invaluable. In years of scheduling, I have seen many large schedules being transferred from one person to another over the life of the project. In almost every case, when the schedule changes hands it goes through major remodeling as the new owner remakes it in a way which makes sense to them.

That being said, there is no reason to throw out sections of plans from previous projects.

I'll cover the rest of this analogy in later installments. Meanwhile there are refreshments in the lobby.

Posted by Jack at 12:37 PM | Comments (0) | TrackBack

May 05, 2005

That is I think I disagree

Must be spring. Everyone (Brian, David, Frank, Hugh) seems to be talking about culture. Or at least "Technology vs. Culture". The basic problem with this is that it is a false dichotomy. Technology is no more the opposite of culture than a Zachary's Spinach and Mushroom Pizza is the opposite of god. (Actually in the latter case one can argue that they are very nearly the same thing - so substitute "submarine" for "god")

Hugh started it by positing that:

There can be no technological solution without a cultural solution. Cultural solutions are more valuable and profitable than technological solutions.

Now before you start bringing up the industrial revolution and perhaps the Luddites I would say that there are some "cultural solutions". Unfortunately, many of these have a darker side, especially when carried out by governments. I'm sure you can fill in the names of the perpetrators of "the Final Solution" and the "Cultural Revolution". But again, it is a fuzzy definition and one can not be entirely clear what a "cultural solution" is.

Brian in Projectified talks about the implementation of Project Server as being a "cultural solution", but then goes on to say "read process as 'culture'". Well, so it isn't culture then is it? Technology is a slave to process. It can enable you to build a pyramid, but in itself it is capable of nothing. It is not something that can be opposed to "culture". There have been many instances where new technologies have helped to shape culture, but only in their application and adoption, that is to say, only as when included as part of a process.

Processes have always had the capability of being either easy and simple or difficult and complex. Except for the most basic, they do require training. A kazoo is a technology for making music. So is a piano. The process of playing Chopin well may take years of practice. Is this practice a "Cultural solution" vs. the technological solution of a player piano?. I do not think so.

Here is the way I see it.

Culture is the environment, for humans it is a set of rules and ideas and habits which are generally accepted and followed. At times it includes certain practices. Process is the action you are undertaking. Technology is a tool to help you do something. How can you oppose these? How can you say one is more valuable than the other? It is like arguing whether the land or the house is the more important. Process is process is process. Some are easy, some are hard. Some go against culture, some go with it. Some use new technology, some are impossible because the technology does not exist. The dichotomy of Technology vs. Culture is just a red herring.

I suppose this is the genius of Hugh McLeod, to pose questions to which the answer is "um, maybe". But it is just a bit disappointing when you get to the bottom of it and find out that the question is bogus afterall.

Nothing to get hung about.

Posted by Jack at 12:48 PM | Comments (5) | TrackBack

May 03, 2005

"Wallyrigged"

Some people I know from another forum are struggling with the definition of the word "wallyrigged". The origins should be self-evident, but here are some examples which cover provenance and illustrate usage:

On the Frontline, Walmart show, they spend some time explaining "pricepoint marketing". This is the cheapest possible price for a item even if it means closing a factory and killing the employees. The intent of pricepoint is to create an illusion of value. To deceive customers into thinking they have obtained a working product.

An example of wallyrigging would be to fix a broken tie-rod with a plastic replacement that had a lifetime warranty, Even though it was clearly marked "Made in China for entertainment purposes only".

A whatever it takes to do something at the lowest cost solution. A total abandonment of concern and consequences is wallyrigging. This is not limited to consumer levels. Wallyrigging starts in the boardroom, is echoed in the halls of congress and born on the backs of average Mericans.

And another real-life example:

For the recent extended family trip, my father bought a cheap Walmart canopy to erect on the beach and provide shelter from the sun. My brother and I went down to the beach with it and poured the contents of the box out on the sand and began assembling the pieces. What a rubiks cube of a mess - in the end, the Chinese widget factory had mislabled one of the snap in support poles and we ended up kluging a fix that lasted until (10 minutes later) a stiff wind bent one of the support poles until the whole contraption looked like it was knelt in prayer towards Mecca. It still supplied a wee bit of shade low to the ground but it looked too much like an OkieQ family-reunion-come-to-Jesus-prayer shrine, so I broke it down and threw it in the trash.

Posted by Jack at 12:46 PM | Comments (0) | TrackBack

Sleeping with the Fishes

I've seen first hand the hardships that cross-site/cross-timezone projects have to deal with and at one time I had the frequent flyer miles to prove it. However, despite those difficulties I find it somewhat hard to believe that this idea to anchor "offshore" workers literally offshore is going to work out.

Showing the picture of the floating cruise ship puts a pretty face on the fact that the people working there will be thousands of miles from their homes and families. On the other hand, my cubicle is a dull grey color and we don't have a company swimming pool.

Posted by Jack at 12:38 PM | Comments (0) | TrackBack