Showing posts from 2011

Bottlenecks: Never assume the experts know better

As the saying goes: "Experts built the TitanicAmateurs built the Ark."

It seems to be human nature to rely on experts and not question their decisions. After all, if they are so clever, who are we to question them?

But sometimes it seems that they are self declared experts and/or it is us who declare them as experts and then believe our own prophecies.

Jerusalem has 2 new fast transport systems: A light rail and express buses. The aim is to eventually replace the latter with another line or 2 of trams.

I always wondered what was the advantage of transport-by-rail - especially intra-city where speed is not an issue.

Light rails are great when they work; the idea is that cars and pedestrians have to keep out of their way, as the trams are inflexible. They are quiet and don't need to tank up as they are electric.

Two weeks ago I saw that anything travelling on rails suffers from the typical bottleneck problem, as to be expected.

First I saw a train that had started pulling out t…

Are all changes really improvements?

I can just imagine it: The yearly review at Egged; the Jerusalem bus cooperative. The major request for change must have been to get rid of the need to punch those paper bus tickets.

It was slow, it meant interacting with each passenger. it meant that the person driving a million-dollar bus spent a good part of his day punching holes into paper; paper handled by other people and he had no way to wash his hands.

So, many years ago they created the monthly bus pass. Now the bulk of travelers simply flash their passes and walk by. What a major improvement.

In parallel they decided to upgrade to the 21st century and computerize the system.

Welcome to CityPass. Each passenger has a debit card - this should really improve things.

But, as often happens, this was not thought through carefully. Now every single passenger needs to insert their bus card into the machine; the driver punches a button and - after the light on the machine turns from red to green - you can remove your card and the line be…

Spec review: Airbags?

One of the many skills a Project Manager needs, is the ability to review functional specifications.

A Project Manager needs to be able to run a spec-review meeting and follow up the action items and document the changes resulting from the meeting.

Another required skill is the ability to persuade people that everything needs a spec and a review.

Why is that? Let's take a non-programming example, for a change; since I've been getting complaints that my blog is very programming oriented.

In 1971 GM added airbags to the driver's side. Since the airbag worked well for the driver, why not install it on the passenger's side also. Source: Wikipedia: Airbags.

Sounds simple enough: Here's what the MRD (Marketing Requirement Document) may have said: "Take existing design of airbag and add it to the passenger side."

Hardly needs a design, functional spec and review, does it? Seems that implementing it will be trivial; what could possibly go wrong?

If anything, it's way…

The End Game: Jerusalem Light Rail

The Jerusalem Light Rail is once again in the news: The drivers all had temporary licenses - all of them expired 3 days ago. Only 12 of them have been renewed. Somebody forgot to take care of renewing all of them...

So now we have the train running once every 30 minutes; even at once every 4 minutes it was crowded...

The Jerusalem Light Rail project is a fascinating one to study; it was running way behind schedule and budget until the current mayor Nir Barkat took charge.

His first question :Where's the schedule and the Project Manager? Yes, he comes from the world of software. :-)

The answer? Well, hum, there were a lot of people in charge; one for the infrastructure, one for the electricity, one for the actually trains, one for the software, one for the traffic lights and the list goes on. But there was nobody in charge of everything.

Result: Everybody could blame everybody else for delaying the project. (The initial launch date was January 2009!)

Nir changed that, and the project sta…

Broken Telephone

A Project Manager spends a lot of time finding out what people are doing and what is preventing them from progressing.

Removing impediments is one of the undocumented roles of a Project Manager; maybe it's time to change that.

Impediments come in a variety of flavors:

Sometimes it's a missing piece from a 3rd party. If the Project Manager can follow up with the 3rd party, then the engineer can  continue doing what she does best, while the Project Manager "wastes his time" chasing the culprit.

Sometimes a lot of non-engineering work needs to be done, like entering a lot of data or editing a lot of existing data. Once again, if the Project Manager can take care of it, the engineer can go back to doing real work. The Project Manager can either do the work or outsource it to somebody who is available; a visiting child or a bored QA member waiting for the project to progress.

Sometimes the Project Manager will discover that the engineer is waiting for a component or informatio…

PMO: Not the prime Minister's office

So, if PMO is not the Prime Minister's Office, what is it?

The Project Management Office (PMO) in a business or professional enterprise is the department or group that defines and maintains the standards of process, generally related to project management, within the organization. The PMO strives to standardize and introduce economies of repetition in the execution of projects. The PMO is the source of documentation, guidance and metrics on the practice of project management and execution. In some organisations this is known as the Program Management Office (sometimes abbreviated to PgMO to differentiate); the subtle difference is that program management relates to governing the management of several related projects.PMOs may take other functions beyond standards and methodology, and participate in Strategic Project Management either as faciliator or actively as owner of the Portfolio Management process. Tasks may include Monitoring and Reporting on active projects …

Internal Competition

Competition is healthy because it's human nature to want to be the winner. Competition is the incentive to work harder - or smarter, and to come out ahead of the other competitors.

That's useful in many areas of life. For example, in schools it drives the serious students to study a little harder, and in business it helps drive prices down and improve service.

When team work is needed, then competition between team members is almost always destructive.

This is true for families; a guaranteed recipe for a disastrous marriage is to have husband and wife compete with one another instead of working together as a team.

In the workplace, the same applies. It's counterproductive when employees see each other as people to compete against. I've worked at many places, and the less internal competition, the more efficient the business will be and more fun it is to work there.

People who are having fun at work are happy to come to work every day and to do a full day's work.

Teams me…

Risk Assessment after Hurricane Irene

Now that Hurricane Irene is behind us, and you've used your Crisis Control skills to salvage as much as possible in real-time, there's a natural urge to start Risk Assessment for the next natural disaster.

However, we cannot predict what the next surprise will be, since then it won't be a surprise. It's even harder to predict how much damage it will cause; nobody could predict the disaster and chaos caused by 9/11 - probably not even the terrorists who masterminded it - including Bin Laden himself.
Most of the time the size of the catastrophe is inversly proportional to the amount of preparation for it.
The trick is to break down the various troubles from the current disaster and group them into distinct categories. Each category then gets treated separately - and each category can be assessed for future prevention, if the risk/cost ratio is high enough. 
Here are some potential groupings - feel free to classify them differently. CommunicationInternet connectivityAccess to …

Give credit where credit is due

Typical amateurish management attitude: It's his job, after all. Why does he also need a pat in the back? He gets a salary!

Giving people credit and compliments makes them feel good. People who feel good work better. So the more opportunities you find for complimenting your team, the more you gain.

That's besides the moral aspect; true they are being paid, but if they achieved something they deserve the credit.

Credits can be given in many ways:

The "about" section can list all the team players; keep it alphabetic to avoid upsetting people.Patent applications can list all those involved, even if their idea didn't make the final cut.Progress reports can highlight those people who made a difference; rotate the names regularly to have everybody included.At company meetings make sure to mention a few people by name.But beware of adding a prize to the credit: If it's not substantial, then it may have the opposite affect:After all those extra late nights all I got was a…

Generic - too much of a good thing?

There's a delicate balance required between making code generic on the one hand, and hard coding everything on the other hand.

Making the code generic can make it easier to tweak things.

For example, if your footer includes a copyright and the year, then you can either hard code the year, and change it every January, or you can write some code to calculate the year, or you can have the code retrieve the year from some properties file.

Here the solution seems obvious; write some code to calculate the year, and never worry about it again. However, debugging this code may be more time consuming than a yearly trivial update.

If you want to be able to control the amount of ads on each section of the page, it's easiest to control this from a properties file. Then you do not need an engineer to update the code!

This seems obvious, but not always feasible. Sometimes the ads have some business logic behind them that would require huge amounts of code to handle a generic solution.

Another pro…

Prototype pitfalls

In software, a prototype seems to work like the finished product. In reality it's usually a pretty face (GUI) with minimal functionality.

If you actually try use the prototype you will discover that it only works for a limited set of actions, if at all.

My first introduction to a prototype was in the mid-1990's. My good friend Jack Kustanowitz arrived at Kivun (of Dagesh fame) as a summer intern. 

Netscape had just released the first Web Browser - and all you could do was browse. Maybe it also had a back button that went to the previous page.

Using Visual Basic, Jack created a prototype of WebTamer; everything your browser needed. Functionality like "History", "Off line browsing" and "Bookmarks".

And it seemed to work! Making a product out of it should be trivial, Project Management was assured. (These were the same non-techie Project Managers from yesterday.)

Suffice it to say that the road from Prototype to Release was long and painful, since the prot…

Why a technical Project Manager?

Is it important that a project manager understand the technicalities of the project she is managing?

In theory Project Management is all about scheduling; finding out what needs to be done, how long it will take, and tracking the results.

There seems to be no reason why the Project Manager needs to understand the technicalities of the project.

I have discovered that this is not so. A Project Manager who does not understand the technicalities, has no idea what she is doing.

Firstly, the team loses all respect for a Project Manager who cannot differentiate between a check-in, a compile and a debug session. As a result they have no problem hiding information from the Project Manager - a guaranteed recipe for disaster.

Many years ago, before I became a Project Manager, I attended the daily meetings of a project, as manager of setups (the installation program).

In the engineering department I was hearing them talking about rewriting the Kernel - that's a huge job and is like a heart transpl…

Eating your own dog food

Obviously if you make dog food you don't want to eat it - but you do want to make sure that your dogs eat it.

If you don't have any dogs, then maybe you are in the wrong business.

Why dog food? That's an old expression, which you can read about here.

If you have no idea how your product works in the real world, then you have no idea how people use it, what problems they have with it and which features they don't understand.

To overcome this you can run a beta-test program. Or you can invite people off the street to come and use it. Often the interaction is video-taped for future analysis.

An important step is to use the product yourself; you, your employees and their families. 

As strange as it sounds, many companies think that they are eating their own dog food, but they are not.

Having the techies use the product is a good start, but not sufficient. After all, they know all the tricks - what the magical shortcuts are and the hidden features.

They also know what not to use, s…

Too much of a good thing?

Since my current full-time job is to find a steady source of income, I have been spending a lot of time on LinkedIn.

It's a great tool for researching potential jobs, since apparently 70% of jobs come from connections. (Who needs protekzia when you have the right connections? J)

The concept is simple: Search for the company that is advertising an opening and discover who you know there - and then ask them to put in a good word for you.

What I noticed was that I had "1st level" contacts almost everywhere. That should be great, except that I would consistently discover that these were all people who had found me and linked up with me over the years - but I have no idea who they are.

Or else they were people who I had linked up with, as they worked at HR companies, or were famous people or vaguely connected to a company I worked at.

Bottom line: I do not know them. So?

So I cannot write them a note asking them to put in a a good word for me, as they have no idea who I am.

And beca…

To be wise or to be right?

Yesterday I was watching a group of kids trying to define an ad-hoc game. They had about 15 minutes of play-time at their disposal.

Most of the kids just wanted to play and make up the minor details as the game went along.

There was one girl who was strong willed and was insisting and defining every possible rule - and she had a strong opinion as to what those rules should be.

Result: They spent the entire 15 minutes defining rules. Not all of them; some of them left earlier in disgust and went to play.

There's a delicate balance between a fully completed  spec and a perfect one.

This is one of those tough calls that a Project Manager has to make. The spec most cover everything. Or must it?

My father tells the story of how the programs in his time - coded on punch-cards (!!!) were able to handle leap years - including the exceptional ones - like the turn of the century. Their systems were Y2K-proof.

After all, they had no idea that the world would progress past punch cards - so the date …