As the saying goes: "Experts built the Titanic. Amateurs 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 the station and got stuck; I have no idea what precisely happened. For about 20 minutes it simply stood there. It was jam-packed and nobody was allowed off. Eventually the driver came around to the cabin at the back of the rain and drove it back to the station and let everybody off.
So what happens to the other trains? They have no way around the stuck train, so essentially all transport heading North was stopped. It was a matter of time until all South bound traffic followed, obviously. (There are a few places where the North and South bound rails have an option to cross over; but running the trains in both directions on the same rail doesn't sound like a great idea.)
Later that day was one of the biggest funerals that Jerusalem has seen. It was close to the rail line. It brought the train system to its knees - for the second time in the same day. Since everybody wanted to get on the train, the train got stuck at every station, as the doors don't close if people are in the way. I sat watching the electronic devices inform us the the next train was in 10 minutes, then 15 minutes and then.... it announced "train stopped". It took 45 minutes for the train to arrive.
Despite them announcing that the next train was right behind (and probably 3 more behind that one) everybody tried to get on this one!
Buses are way more efficient! I often seen 3 buses play leap frog; one fills up at a bus stop while its twins head for the next stops.
Even in the express bus lanes, a bus will overtake another, if the first bus is stuck or taking too long to move.
There is a way to get both the advantages of quiet electric transport and not have to deal with rails.
In Johannesburg they used to have (and probably still do, but I have not been there in over 20 years) double decker electric buses with 2 antennas connected to the overhead electric lines. If a bus got stuck it could be unhitched from the wires and other buses could get by.
They also had to do load balancing; if too many buses were behind each other trying to get up some of the steeper hills, then they all would get stuck unless some of them stopped, giving the power back to the ones in front.
Maybe the light rail was not such a brilliant idea after all...
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 behind you can advance slightly.
As an added bonus, at major bus stops (like the Central Bus Station) you can no longer enter by the back door after an inspector punches your card.
Net result: Travel time by bus has increased noticeably.
A spec-review would have been in order here! A project manager would have picked up on issues like:
- The machine which validates the cards better be lightning fast if the driver is to deal with each passenger
- Alternatively there could be card readers at every door so that the driver does not have to deal with any passengers. This is how the light rail has it planned out. On 1 Dec we shall find out if their system really works.
A few simulations would have picked up these issues.
Now I'm waiting to see what happens as the magnetic strip on the cards start be wear out... that will surely wreak havoc on the system as people alight and discover their bus cards are dead...
Conclusion: Not every change is an improvement.
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 behind you can advance slightly.
As an added bonus, at major bus stops (like the Central Bus Station) you can no longer enter by the back door after an inspector punches your card.
Net result: Travel time by bus has increased noticeably.
A spec-review would have been in order here! A project manager would have picked up on issues like:
- The machine which validates the cards better be lightning fast if the driver is to deal with each passenger
- Alternatively there could be card readers at every door so that the driver does not have to deal with any passengers. This is how the light rail has it planned out. On 1 Dec we shall find out if their system really works.
A few simulations would have picked up these issues.
Now I'm waiting to see what happens as the magnetic strip on the cards start be wear out... that will surely wreak havoc on the system as people alight and discover their bus cards are dead...
Conclusion: Not every change is an improvement.
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 more complicated to add it to the driver's side, since the steering wheel is in the way.
Fortunately they did a spec review, and here's some of the issues that were revealed:
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 more complicated to add it to the driver's side, since the steering wheel is in the way.
Fortunately they did a spec review, and here's some of the issues that were revealed:
- What happens of an infant is in the passenger seat? Won't the airbag serous injure / kill it?
- Solution: Put a weight sensor. Do not deploy if weight less that 3 year old child.
- Action item: Find out minimum weight from medical dept.
- Action item: Inform legal that a new "anti-infant" clause needs to be added to standard car contract.
- What happens if the infant is in a car seat? it will be heavy enough to be detected as an adult... yet the result could be fatal...
- Add switch to manually override the airbag.
- Where should we place this switch? passenger side? drivers' side? in between?
- Since it's to protect infants, needs to be on driver's side.
- Needs to be far enough away from passenger that kids don't play with it during travel.
- Does it reset when ignition is turned off, or does it remember its state?
- Could be fatal if it resets; better if it remembers state.
- Add a warning beep to sound when airbag is turned off.
- Add a warning beep if passenger is too light and airbag is turned on.
- How can we prevent it being turned off accidentally?
- Maybe it should require car-key to flip on/off.
- Decisions: try both options and track customer feedback.
- Add light to dashboard to indicate that airbag on passenger side is deactivated.
- Action item: Design relevant icon - graphics dept.
- How will drivers know when to turn the airbag off, and what all the icons and beeping mean?
- Action item: Get stickers made to explain the infant-hazard; get wording from legal, design from graphics dept.
- Should airbag always deploy?
- Maybe it should only deploy if the seat-belt is buckled? This way it won't unnecessarily if only groceries are in the passenger seat.
- On the other hand, the airbag is most useful when the passenger is not wearing their seat-belt.
- Decision: Deploy independently of seat-belt being buckled.
As we can see, this trivial, easy to implement feature has become a project involving the following departments: legal, graphics and medical.
It requires a redesign of the buttons sections and the icon on the dashboard. It also requires a new type of switch that gets turned by the key.
We now know why the first passenger-side airbags didn't appear until 1973.
Finally, we also have plenty information in order to create a full-length functional specification, which everybody will understand why it's needed, and many people from various departments will be required to review.
So now we know!
- Danny Schoemann
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:
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
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
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
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
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
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
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.
When the Eyjafjallajokul volcano erupted, it caused airports all over Europe to be closed. Had your emergency flight plan called for racing across the continent from Belgium to Italy to catch a flight, it would have been useless as a backup plan.
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.
- Communication
- Internet connectivity
- Access to our web site
- Access to our email
- Access to our customer support system
- Phone connectivity
- Mobile phones
- Land-lines
- Inter-office communication
- List of key people's home phones
- List of team-leaders contact info
- Escalation plan for:
- Emergencies
- Helping each other
- Moral Support
- Access to office
- Physical access
- Emergency exits
- Virtual access to email
- Access to sensitive info like passwords
- Backup and Restore
- Web sites
- emails
- Personal PCs
- Off-site backup
- Faster Restore
Each item on the list then needs to be taken care of. There are few - if any - generic solutions.
Let's work through the first item on our list: Access to our web site.
During the storm, our web site may have been inaccessible either because the electricity went out, or the internet connection died or the site was overloaded because of too many home-bound people trying to access it.
If our web site went offline during the storm, then we may want to have it hosted in more than one location. Unless it's a web site for the local population, and if the power to the web site goes down, then our entire user base cannot access it either, so there would be no need to be online.
- This highlights why the disaster control plans need to be updated periodically. Nowadays that mobile phones are everywhere, the above presumption is no longer valid. There maybe no electricity or internet within 100 miles of your user base, but you can be 100% sure that many - if not most - of your users will be online from their mobiles, hand-helds, iPads, iPods and other wireless technology.
But simply deciding on distributing your internet hosting is not enough. It needs to be implemented. If your system was not designed for being hosted at multiple sites, this could be a major project. At some stage, management will have to make a decision. To help them, you want to have figures of:
- The cost of damage to our reputation and traffic by remaining at a single site if it becomes unavailable for a day / week / month.
- There's also the cumulative cost, of people never coming back to a site that was down for more than a few moments.
- The monthly financial cost of hosting at 2 or more sites.
- The cost of maintaining more than one site for both engineering, QA and IT.
- The cost of the design, engineering and testing efforts required to upgrade the system.
A final decision point to take into consideration is that the other site chosen may also be targeted by the next disaster.
Hurricane Irene proved that the 500 miles between NC and CT are not enough when doing hurricane Risk Assessment. An elementary understanding of weather patterns, the national electricity grids and the internet backbone would be required to decide on the safest location for hosting the mirror site.
If the decision is taken to implement the dual-location of the web site, then the implementation has to be tested to ensure that if either site goes down, then the other site will manage to run solo. It has to be able to handle the load; not only double the regular load, but maybe double of that, since during emergencies the site tends to get more traffic, either because it has useful information, or entertains those who are home-bound due to the circumstances, or maybe because the competition was not prepared to implement multi-site hosting.
Side benefit: Once we have multi-site hosting for out web site, maybe we can use it for other items on the list:
- Email access
- Lists of passwords and phone numbers
- Escalation plan
- Customer support
- Off-site backups
But don't assume that any of these solutions are trivial; you have to take into account issues such as security and access control when sensitive information is made available online.
In conclusion, identifying the trouble spots is only the first task. At some level it's the easiest one. Implementing solutions is harder. In future posts maybe we'll analyse what needs to be done for other items on the list.
Risk Assessment and Crisis Control are full time jobs; and the more time you spend on them, the more you'll be prepared for the next surprise that nature or mankind will spring at you.
- Danny Schoemann
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:
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 meal for 2?
- It can create internal competition - something we'll discuss in a future post.
- It can put a monetary value on effort and people will start comparing their effort to their prizes and invariably you will get some unhappy campers.
- When finances get tight the first thing to go will be the prizes; and that's the time you need the most goodwill from your team.
Even sending out a company-wide "Happy Birthday" note to the daily celebrants is a way to make them feel special. If this comes with a birthday gift, then make sure that everybody (in a 6 - 9 months period, if not a full year), get the identical gift.
Another way of giving credit, saying thank you and making every feel appreciated is to occasionally give out freebies. Company T-shirts, pens and other give-aways can do the trick. If you order them for clients or fairs then order enough to also give one to each employee.
Celebrating major milestones or releases is another way to say Thank You to the teams involved. Ordering a cake or having some fun time with some games / quizzes or similar will cost the company 2 - 3 hours and will create the goodwill you need to start the next project with new energy.
Giving credit for non-job related tasks is also effective. Be it for somebody who keeps the coffee area clean or who starts an internal book club or even for somebody who did something outstanding in their private life.
Even though it's not work related, the person deserves a round of applause, and it will make them and their friends feel better - and they will all have a more productive day.
On the other hand, don't overdo it. Sending out a company-wide Bravo email when somebody does a 2 hour fix, is silly and shows that you don't understand the effort that goes into the bigger tasks. If you feel that a particular minor job was well done, then email that person - and her boss - but not the entire company.
Give credit where credit is due, and your team will respond by giving you lots of opportunities to give them credit. It's a win-win deal.
- Danny Schoemann
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 problem could be error handling. Do you assume the values entered in the properties file will always be there and will always be correct? What happens if somebody enters a capital-Oh instead of a Zero? (Is this 2O or 20?)
Adding error handling has its own challenges. If the values are wrong, what values do you use? Who does the code inform and how? (You cannot show an error on the page; imagine thousand of users seeing "Bill, there's an error in the x value". Chances are that everybody but Bill will see this.)
In the mid-1990's setups went from being written in Microsoft's Setup-Basic to becoming sophisticated in order to handle the requirements of Windows-95; uninstall.
Since we created a new SKU almost daily, it made sense to create the new setup system as generically as possible.
The result was the following:
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 problem could be error handling. Do you assume the values entered in the properties file will always be there and will always be correct? What happens if somebody enters a capital-Oh instead of a Zero? (Is this 2O or 20?)
Adding error handling has its own challenges. If the values are wrong, what values do you use? Who does the code inform and how? (You cannot show an error on the page; imagine thousand of users seeing "Bill, there's an error in the x value". Chances are that everybody but Bill will see this.)
In the mid-1990's setups went from being written in Microsoft's Setup-Basic to becoming sophisticated in order to handle the requirements of Windows-95; uninstall.
Since we created a new SKU almost daily, it made sense to create the new setup system as generically as possible.
The result was the following:
- A code base that was too big for the debugger; so we could no longer "see" what the program was doing, and finding bugs became really difficult. This was because retrieving each value from a properties file requires many lines of code, to ensure it was fail-safe.
- A properties file that was over 1,000 lines long. That's a lot of control over the minor details! But it's also impossible to control; fine tuning setups via the properties file was very tricky and error-prone.
- Since Product Management and Marketing were very creative, they demanded new twists we had not thought of. Once they would decide on a 3rd party disk we should install, another time they added a registration screen and then it would be a registration code or a "time limited" edition. Each of these great ideas required writing new generic code and adding more lines to our properties file.
- Once we had the templates for all our products, setups for similar SKU's became trivial. Adding or removing a language was easy. The engineers in certain groups took care of the own setups.
As Project Manager, I always ask the engineers to write code keeping in mind that it may be need to be changed regularly.
- If it's something we know we want to test all the time, (like the number and placement of ads) then it should go into a properties file.
- If it's something we will tweak once or twice (like a font size or color, and an experimental object that we want to test and either keep or discard) then it should be easy to find and easy to change. Don't make this particular object dependent on others, don't make other object depend on it - and put some comment in the code to make it easy to locate, even in 6 months time when you no longer remember the code.
This creates some balance between the joys and pains of being generic and being hard coded.
And this is another example of the advantages of having Project Managers who used to be techies.
- Danny Schoemann
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 prototype was mainly a GUI; a pretty face, and Jack-the-wiz-kid was back in college.
Prototypes of the graphical interface are easy to create, very impressive and very misleading to Project Management - and Management in general. It's hard to see why a product which looks ready-to-use will need months of development before it can be shipped.
Sometimes a prototype is used as a technical proof-of-concept. Being unsure of the capabilities and limits of certain technologies, a team will implement some functionality with technology they have never used before. Usually some new emerging technology.
They can then measure:
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 prototype was mainly a GUI; a pretty face, and Jack-the-wiz-kid was back in college.
Prototypes of the graphical interface are easy to create, very impressive and very misleading to Project Management - and Management in general. It's hard to see why a product which looks ready-to-use will need months of development before it can be shipped.
Sometimes a prototype is used as a technical proof-of-concept. Being unsure of the capabilities and limits of certain technologies, a team will implement some functionality with technology they have never used before. Usually some new emerging technology.
They can then measure:
- How long did it take? Does this seems like a faster way to implement features?
- How stable is it? If we stress the application does it crash or slow down?
- How fast is it? If they implemented existing functionality, they can benchmark it to see if it's faster or slower than the existing implementation.
In this type of prototype, the important functionality will be there, but the GUI may be missing.
Can the prototype code be used in the end product? Sometimes; often it cannot as the prototype will have been done without a technical design; that crucial design stage that ensures that multiple programmers can safely and efficiently work on the same code.
What a Project Manager needs to realize is that prototypes - both types - are not an indication of a finished product, no matter how good the demo looks or functions.
The connection between a prototype and the end product is often similar to the connection between an ad and the actual product, or the trailer of a movie and the actual movie. You've been shown the highlights; the devil is in the details.
Lessons learned:
Having a "working prototype" will not in any way shrink the schedule. "It's almost ready" is not true.
A prototype does not absolve the Project Manager from creating a fully blow functional specification document. Assume all the functionality is missing. What you see in not what you will get.
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 transplant.
In the daily meetings I was hearing the engineers inform the Project Manager that the project will ship on time - a few days hence.
Six months later the project was almost ready to ship, and I was convinced that I wanted to become a Technical Project Manager.
Had the Project Manager been technical, she could have asked what the team is up to, and understood that rewriting the kernel is going to be a long task.
Another reason for a Project Manager to understand what technologies are being used and what they do, is in order to catch inconsistencies as early as possible. As an objective bystander (after all, she is not going to write any of the code), she may often see issues which the people involved do not realize.
I have also seen ex-programmers turned Project Manager help come up with great (and simple) technical solutions; sometimes the people involved in the work do not see the forest from the trees - and a simple solution is best.
In my experience, I find that I can estimate the scope of a project before discussing it with the engineers. This way I can tell if the engineer is guesstimating in the correct ball-park, or if she is way-off. I can then discuss with them what they base their estimates on.
The Project Manager is more than the conductor on the bus, who does not need to know how to drive. She is also not simply the air-hostess who needs to ensure everybody is comfortable, but will never need to fly.
An efficient Project Manager needs to be a co-pilot; somebody who is aware of the meaning of all the pieces involved.
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 transplant.
In the daily meetings I was hearing the engineers inform the Project Manager that the project will ship on time - a few days hence.
Six months later the project was almost ready to ship, and I was convinced that I wanted to become a Technical Project Manager.
Had the Project Manager been technical, she could have asked what the team is up to, and understood that rewriting the kernel is going to be a long task.
Another reason for a Project Manager to understand what technologies are being used and what they do, is in order to catch inconsistencies as early as possible. As an objective bystander (after all, she is not going to write any of the code), she may often see issues which the people involved do not realize.
I have also seen ex-programmers turned Project Manager help come up with great (and simple) technical solutions; sometimes the people involved in the work do not see the forest from the trees - and a simple solution is best.
In my experience, I find that I can estimate the scope of a project before discussing it with the engineers. This way I can tell if the engineer is guesstimating in the correct ball-park, or if she is way-off. I can then discuss with them what they base their estimates on.
The Project Manager is more than the conductor on the bus, who does not need to know how to drive. She is also not simply the air-hostess who needs to ensure everybody is comfortable, but will never need to fly.
An efficient Project Manager needs to be a co-pilot; somebody who is aware of the meaning of all the pieces involved.
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, since it is delicate or broken.
Watching the secretaries, accountants and office managers use the product is more enlightening.
You may discover that the non-techies have a hard time using the product.
At Answers.com we were surprised to discover that some of the accountants could not figure out the Alt-click; something the techies took for granted.
Make sure that they have a contact person they can call to help them. This person will want to document what the issues are - and Product Management will want to analyze what needs to be improved.
The Project Manager would do everybody a favor to run this experiment periodically, and to talk to each and every non-techie to see if they actually are using the product. Often a period of "no complaints" simply means that the product is not being used.
This in-house experiment will also test the upgrade-process: How to ensure that your user base is using the latest version of your product.
If you cannot eat your own dog food, you need to ask yourself if you're making the correct product, because of you can't use it, then why should anybody else?
Bon appétit!
- Danny Schoemann
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, since it is delicate or broken.
Watching the secretaries, accountants and office managers use the product is more enlightening.
You may discover that the non-techies have a hard time using the product.
At Answers.com we were surprised to discover that some of the accountants could not figure out the Alt-click; something the techies took for granted.
Make sure that they have a contact person they can call to help them. This person will want to document what the issues are - and Product Management will want to analyze what needs to be improved.
The Project Manager would do everybody a favor to run this experiment periodically, and to talk to each and every non-techie to see if they actually are using the product. Often a period of "no complaints" simply means that the product is not being used.
This in-house experiment will also test the upgrade-process: How to ensure that your user base is using the latest version of your product.
If you cannot eat your own dog food, you need to ask yourself if you're making the correct product, because of you can't use it, then why should anybody else?
Bon appétit!
- Danny Schoemann
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 because they don't know me, they never offer me a job. So what's it help to be connected to them?
Even worse: Since I am on "1st level" terms with these people and their company, I cannot easily see who we know in common; people who I may actually know and who could put in a good word for me.
So, I did the painful move of removing contacts! Painful because LinkedIn makes it rather difficult to remove about 100 contacts, painful because I had to double check that these are actually people I can safely remove, and painful because I hate throwing things away - no matter how useless they are.
I still have over 480 contacts - and that number still needs to shrink. So now, every time a contact "gets in the way", they get removed.
So if I refuse to link to you and point you to this post, you know why.
That said, on FaceBook, I have given up. I have almost 1,500 friends - and I probably know about 10% of them. But since these are people who want to read my Halocho-a-Day post, I have agreed to befriend them.
On FaceBook I only unfriend people who bug me with nonsensical posts are other forms of spam.
In Project Management one sees the same thing; sometimes involving too many people is counterproductive, and sometimes everybody needs to be informed. The trick is to be able to differentiate between the 2 cases.
- Danny
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 because they don't know me, they never offer me a job. So what's it help to be connected to them?
Even worse: Since I am on "1st level" terms with these people and their company, I cannot easily see who we know in common; people who I may actually know and who could put in a good word for me.
So, I did the painful move of removing contacts! Painful because LinkedIn makes it rather difficult to remove about 100 contacts, painful because I had to double check that these are actually people I can safely remove, and painful because I hate throwing things away - no matter how useless they are.
I still have over 480 contacts - and that number still needs to shrink. So now, every time a contact "gets in the way", they get removed.
So if I refuse to link to you and point you to this post, you know why.
That said, on FaceBook, I have given up. I have almost 1,500 friends - and I probably know about 10% of them. But since these are people who want to read my Halocho-a-Day post, I have agreed to befriend them.
On FaceBook I only unfriend people who bug me with nonsensical posts are other forms of spam.
In Project Management one sees the same thing; sometimes involving too many people is counterproductive, and sometimes everybody needs to be informed. The trick is to be able to differentiate between the 2 cases.
- Danny
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 formula was written for posterity.
At the time it was probably the best decision: the date formula is used all the time and adding an extra condition in the code was not a big deal.
After a spec is written, there is a spec-review meeting - where all those who will be involved in the implementation and testing should be invited; attendance is conditional on having first read the spec.
At those meetings there will be some heated debates about missing features or how to implement seemingly trivial functions.
The key is to listen carefully to what is not being said. Very often one of the vocal (loud or insistent) reviewers of a spec has a hidden agenda: e.g. a pet concept or implementation that they want to use - or learn how to use.
Or a skill set they want to use. Or a fear of the unknown. Sometimes it may be a (self declared) expert who (erroneously) thinks she needs to have original input to everything, otherwise she'll lose her job.
Sometimes it is a simple case of "Perfection is the enemy of Completion".
A trick that I learned for all meetings that get side-tracked or are taking too long: After 30 - 45 seconds simply interrupt the interruption and say "let's take that off-line".
Write it down and make sure to follow up (usually with an email, to as few people as possible) - otherwise they will stop letting you use that line.
Often the follow-up email will be the end of the story. After all, the proposed concept was only to gain attention during the meeting and not to actually try improve the spec.
Sometimes the ideas being suggested are correct - but will kill the scope of the project. Be realistic about the life expectancy of the project.
besides, it's often best to ship a feature-free product ASAP and then - if it's a success - to release frequent updates.
It's better to get requests for more features rather then complaints about poorly implemented features.
- Danny Schoemann
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 formula was written for posterity.
At the time it was probably the best decision: the date formula is used all the time and adding an extra condition in the code was not a big deal.
After a spec is written, there is a spec-review meeting - where all those who will be involved in the implementation and testing should be invited; attendance is conditional on having first read the spec.
At those meetings there will be some heated debates about missing features or how to implement seemingly trivial functions.
The key is to listen carefully to what is not being said. Very often one of the vocal (loud or insistent) reviewers of a spec has a hidden agenda: e.g. a pet concept or implementation that they want to use - or learn how to use.
Or a skill set they want to use. Or a fear of the unknown. Sometimes it may be a (self declared) expert who (erroneously) thinks she needs to have original input to everything, otherwise she'll lose her job.
Sometimes it is a simple case of "Perfection is the enemy of Completion".
A trick that I learned for all meetings that get side-tracked or are taking too long: After 30 - 45 seconds simply interrupt the interruption and say "let's take that off-line".
Write it down and make sure to follow up (usually with an email, to as few people as possible) - otherwise they will stop letting you use that line.
Often the follow-up email will be the end of the story. After all, the proposed concept was only to gain attention during the meeting and not to actually try improve the spec.
Sometimes the ideas being suggested are correct - but will kill the scope of the project. Be realistic about the life expectancy of the project.
besides, it's often best to ship a feature-free product ASAP and then - if it's a success - to release frequent updates.
It's better to get requests for more features rather then complaints about poorly implemented features.
- Danny Schoemann
Subscribe to:
Posts (Atom)
Meet the author!
Do Projects Ever End Early?
Finally, after many years of thinking about it, my book, titled " Do Projects Ever End Early ?" is ready to download. Do Projects ...
