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 started moving. When the August 19, 2011 deadline loomed large, those involved started their old story about not being ready. Nir wanted to know what wasn't ready.


The billing system? Too bad. The train will have to be gratis until you get that one right.  Apparently the system crashed when it was tested in real time; lots of people buying tickets all over the city at the same time. Would make an interesting study in design and testing.


The obvious advantage is that the trains are free, meanwhile. The disadvantage is that they are full to capacity, as every loafer in town - and all bored kids - spend their time on the air conditioned trains.


The traffic lights are not synchronized yet with the train? Too bad. They will have to stop at the red ones. (It's really pathetic; at the main bus station there's a traffic light for pedestrians to cross the rails. It's not synchronized (or needn't be) with any other traffic light. Yet the train often has to stop, since it's green for the pedestrians - all of 10 feet from the train station!) 


Supposedly they are working on this project; hopefully not the same people in charge of the licenses.


How they plan on synchronizing the traffic lights for the train without grid-locking vehicular traffic is  not clear to me. I'd like to believe that there are experts on this subject who know better than me.


The trains sometimes run off the rails? This was discovered in high-speed testing. Solution: Drive slowly until we figure this out. Makes one wonder why the rails are needed...


The advantage is this even if you can see the trains approaching, you will often manage to get to station before the train, since it also drives slowly and also gets stuck at all the traffic lights.


Lessons for Project Managers:

• Without a single Project Manager in charge of everything there's going to be chaos. Each major element can have its own Project Manager, but they all have to report to a single person.
• Ship as soon as something is ready; early users are as good as beta testers.
• Ship often, with minor improvements.
• Not every "bug" or "issue" is a showstopper and a reason not to ship.
• Think of creative solutions. Sometimes the experts know too much, and need to be overridden. 

There's probably more obvious lessons; feel free to add them in the comments.


In a future post we'll discuss how Egged rolled out the CityPass; enabling single payment for both trains and buses.

- Danny Schoemann

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 information from another engineer. It's best practice to go to that other engineer and double check that they realize that somebody is waiting for them to deliver something.
Find out if it's on the top of their list of things to do; you do not want an engineer waiting for something that  may take a long time to arrive, since it's not on the list of things to be done in the immediate future.
If there's a conflict of scheduling (one fellow needs it now, the other fellow has no intention delivering it this week) then it needs to be escalated.
It can be brought up the the daily update meeting, if they happen. More efficient is to simply approach the head of engineering and ask her to intervene and solve the conflict. She may decide a meeting should be called, or she may decide to change priorities on the spot.


Sometimes a Project Manager will discover that one person is expecting something to be delivered and the other party claims they already delivered it.
One solution  is to go back and discover where it was delivered to and how come it never arrived.


Better yet, is to get the 2 engineers to talk to each other - else you may spend considerable time playing broken telephone. Besides, it's important to teach the engineers that they can talk to each other. :-)
The best tactic is to ask the one engineer to accompany you - the Project Manager - to the other engineer, and to have a impromptu meeting.
Listen carefully to how they solve this; it may give you valuable insight into the personalities and work habits of the engineers. This is information that will help you preempt future similar issues.
And make sure to follow up to ensure that the solution actually worked. There's often a gap between the theory and the facts on the ground.


As a rule, you do not want to be spending time as a go-between - the broken telephone - between people. A quick stand up often solves the problems.


- Danny Schoemann

PMO: Not the prime Minister's office

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


From Answers.com

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 (following up project until completion), and reporting progress to top management for strategic decisions on what projects to continue or cancel.

So, what do we have here? Looks like somebody tried to split the classic Project Manager's job into various smaller jobs. To me, the obvious result will be more overhead - as more people are involved - and less efficiency, as a Project Manager needs to have full control over his project.


I've been part of attempts to have more than a single PjM on a project. It simply does not work; the Project Managers have to spend huge amounts of time coordinating between themselves, or else they step on each others toes and either do duplicate work or send out mixed messages.


If a single Project Manager cannot manage the project, then it needs to be split into almost unrelated mini-projects. Then it seems to make sense to have a PMO, but, on second thought, to be efficient, there would be too many meetings and updates and not enough hands-on Project Manager. Having each Project Manager attend the status-update meetings of the other projects and receive its updates would be more efficient.


So let's analyse what the PMO does:


[The PMO is] the department or group that defines and maintains the standards of process, generally related to project management, within the organization.


I smell trouble. A group of people who want to regulate Project Management. :-)


The PMO strives to standardize and introduce economies of repetition in the execution of projects. 


At some level, Project Management is all about repetition. Get daily updates, have daily meetings, check the bug-count status daily, update the schedule and send out a daily update.


I'm not sure I understand what they are trying to save, unless they are worried that similar projects will be initiated. But who would initiate these projects? Surely all Project Managers keep up to date with what's going on around them; at least on a high-level.


If we're talking about duplicate code or similar testing - that would be the job of the head of engineering/QA to take care of.


The PMO is the source of documentation, guidance and metrics on the practice of project management and execution.


This will ensure that the Project Manager has no connection to the rules, and therefore will ignore them and/or make up new ones. The most efficient rules are put in place by people who learned the hard way. Besides, with the fast evolution of technology, any rules that are 3 years old will be archaic. New rules need to be put in place all the time by the people involved, not those disconnected from the field.


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.


Again, my experience is that a Project Manager is most efficient when he's in full control. If this facilitator is not on the same wave length (and starts arguing with the PjM at meetings) then the PjM will lose control of the project. Advise to PjM's needs to be given privately, not as a facilitator at meetings.


Tasks may include Monitoring and Reporting on active projects (following up project until completion), and reporting progress to top management for strategic decisions on what projects to continue or cancel.


That's what a Project Manager does. 


Maybe a PMO works well in huge organisations where there is a total disconnect between the projects and management. I would love to work in or with a PMO for a while in order to understand what it does.




- Danny Schoemann

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 members who are not in competition with each other are happy to help each other. They also have no issues about constructively criticizing each other's work and ideas. This dramatically improves throughput.


When team members compete with each other they may hide information from each other, which wastes huge amounts of time. In extreme cases they may sabotage one another's efforts. That's already destructive behavior and the business is sure to suffer.


Many things contribute to the internal competitive attitude.


Management is where it all starts. If managers compete with each other, that sets the tone company-wide.


If management creates a huge structure where everybody needs a title - and titles become important - then people will start competing with each other for the titles.


Management should channel the competitive urge towards the real competition: external competitors and potential competitors.


Project managers can help, too. The internal competition should be "everybody" against the "deadline". Pretend that the enemy is the deadline or the amount of open bugs, and create an atmosphere of "we will work as a team against the deadline".


Very often two brains are better then one; 2 sets of eyes are better then one, and having people work in ad-hoc teams doing pair-programming can achieve amazing results. If somebody always has to get the credit, then nobody will want to share.


For this reason it's best not to single out employees as "winners" or "employees of the month" unless they have done something extraordinary. It's best to cheer on the entire team as a unit; they'll gladly all go out together for a meal or a day in the sun - and this will reinforce the team spirit.


Another team-spirit killer is individual goals. People will do everything and anything to meet their personal goals, even at the expense of killing a bigger goal, like a team goal. Team-wide goals are fine as long as they do not create friction between teams.


Even between teams, you do not want unnecessary competition. QA and Engineering should be working together to create the bug-free product. Pitting one against the other achieves nothing. It's most productive when the testers and programmers can sit together; one showing how it can be broken and the other trying to fix it.


So what do you do if you absolutely feel that somebody deserves extra recognition? For example, somebody cleaned the kitchen-area and made it kosher-for-Passover?


The best thing to do is to tell them privately how much you appreciate going the extra mile. You could give them a gift certificate without any fan fare. In a healthy non-competitive environment, they will appreciate the privacy as well as the recognition.


Even when punishment is needed, or a post mortem is called for, it needs to be done at the team-level. More about that in a future post.

- Danny Schoemann