Showing posts from July, 2011

Preparing for disaster

You don't plan on having a fire burn your business down, yet you do have insurance, fire extinguishers handy, as well as sprinklers and alternate exit routes.

Why? because you want to be ready to tackle the fire when it's a mere flame, so that it doesn't do more damage than needed. You also want to be able to recover as fast as possible.

Similarly, you want a backup plan for your business and for each project.

This could involve:
Backup plans and restore plansOff-site copies of important dataDistributing your data centersKnowing your people's skill sets to be able to replace them and/or switch between themEach of these deserves a post of its own. A post that almost anybody could write, and probably should; for their own project.

An overlooked part of the plan is data collection.

In future posts we will elaborate on:
Which data to collectWhen to collect dataHow long to store the dataKnow how accurate your data isTracking changesWhen everything is going well, the need for data …

Solutions, not problems

As I mentioned previously, I'm used to have 2 signs hanging on my office wall. One of them says "Perfection is the enemy of completion".

The second sign says "Solutions, not problems".

It's a Project Manager's task to spot problems as they happen, or even to predict problems that are bound to happen.

However, nobody is interested in problems. What they want - and need - is solutions.

So, unless you are dealing with an emergency, you do not want to report a problem unless you have some sort of idea or direction of a solution.

Actually, even in the case of an emergency you will want to report a solution, though it is usually is the kickoff meeting for the Crisis Control.

The best way to find a solution is to talk to those who will have to solve the problem, and ask them for ideas.

Once you have a clear definition of the problem and possible solutions, then you want to escalate the problem and its solution to whoever needs (and wants) to know.

Why escalate the pr…

Sync up in 15 minutes: The daily stand-up

The more people involved in a project, the harder it is to keep everybody in sync.

Sending status updates by email sounds like a good idea until you try it. At some point (after about 2 emails) most people stop reading them; they seem so repetitious.

Having a meeting should work, but it is very time consuming, and to be effective everybody needs to be persuaded to arrive on time. In reality many people's minds start wandering during meetings, unless their specific part is being discussed.

What does seem to work is a daily 15 minute stand-up:
Daily: This way the updates are short and few, allowing people to concentrate.15 minute: This wastes little time and gives people an incentive to arrive on time, else they miss the entire meeting.Stand-up: Once seated, people are happy not to move for a while, and meetings can drag on. When standing, people are happy to end the meetings quickly.Where to do the meeting? We used to do the meetings at the Kanban board which had all the tasks laid out…

Deadline: Friend or foe?

Deadlines are a double-edged sword.

Without deadlines there would be no pressure to get a project finished. Projects without deadlines can continue forever, as people continuously add features and try perfect the product.

More seriously, work tends to fill up all available time. So, if there is no deadline - or a very generous deadline, all the available time will be used up; and the project will still have trouble getting to a finished state.

On the other hand, deadlines create pressure.
Some people don't work well under pressure, and their work would be better if there was no deadline, or a very far-off deadline.Deadlines cause people to take shortcuts, in order to meet the deadline. This could be a a pity, if the deadline is fictitious; it simply means that the project will need a follow-up project to clean up from the mess caused by the deadline.When working in continuous-release mode, deadlines can be ignored. Whatever is ready by the release will be shipped; whatever is not read…

Perfection: the enemy of completion

I'm used to have 2 signs hanging on my office wall. One of them says "Perfection is the enemy of completion". (The second sign I'll keep for a future post.)

As much as we all assume we are perfect and can produce bug-free products, reality simply does not allow it.

For example:
If your product works perfectly on newer browsers, it won't work well on older browsersIf your product is designed for older browsers, it will look really outdated on all browsersIf your product runs well on newer versions of windows, it won't work at all on old versions; and vice-versaBut even of you target only a specific subset - e.g. a single version of a single model of a mobile phone - you still can't produce perfect software, unless you are writing a tiny application.

Since nowadays applications are event-driven, you can never tell in what order the user will use the software. They may do things that you never would imagine.

What you can do is have robust error handling, so that …

Is Project Management all about scheduling?

The short answer to "Is Project Management all about scheduling" should be "No".

However, that has a caveat. based on my experience, if a Project Manager insists on keeping the schedule up-to-date, then scheduling will become his full-time job.

As we already mentioned, schedules are always out-of-sync with reality; while you are updating them the reality is changing. As a result, you will spend 100% of your time updating and collecting updates.

In a future post we will discuss EVS (Earned Value System). The most important lesson I learned from using EVS was this. It's irrelevant whether the task is 41% complete or 78% complete. It's either 0% (not started), 20% (started), 80% (ready for testing) or 100% complete, having been blessed by QA.

This saves a lot of useless schedule updates, which are meaningless since nobody really knows how long the task will take, and often the last 20% of the task takes 80% of the time. More about that in a future post.

So, "I…

Schedule: Why bother?

Most schedules are outdated before you finished typing them.
"Remember that 5-day task? I finished it already; took me 45 minutes.""About that 1-day task... it's going to take at least 2 weeks, because...."So why bother making a schedule?

1. It sets Expectations:
Engineers now know what delivery date management would like. Some - if not all - people work better when they have a target, and they know they are being watched.Management has an idea how long it will really take.
2. It creates a Task list:
By asking all those involved how long their piece will take, they will [hopefully] come up with most of the missing pieces; items you probably never knew needed to be done.It also enables the change control process, since items not on the schedule are out of scope.
3. It creates a Baseline:
This is important if you want to learn for future projects. This way you can measure which team members are better than others at guessing how long something will take to implement.T…

Scheduling in the 21st century

Surprise! In the 21st century the art of scheduling - and the joys of creating elaborate Gantt Charts  - is becoming less and less relevant.

Why is this so?

Because  - at least in the software world - projects are being delivered continuously!

As soon as there is something to ship, it can be uploaded to the web, and as improvements are made, they can be tested and shipped as updates.

However, there still are some large projects that need industrial-strength schedules.

The easiest way to schedule a large project, is to find out when the boss wants it delivered. This way at least one person will be happy with the initial schedule. :-)

How long does it take to write new software? The real answer is: "we don't know", since this piece of software has never being written. If it had been, then we wouldn't be writing it again.

Experienced programmers do have an idea how long it will take them; experienced Project Managers will know how to gauge that estimate and how much padding to…

The Quick, Small change

Axiom: There is no such a thing as a quick and small change to a program.

Unless you're a one-man team with a simple program, every change is going to cost you time, debugging and possibly bugs and frustrations.

Let's take an easy change: remove the extra period at the end of a sentence..

This is something a Project Manager may even be able to do by themselves, if they know how to use the Version Control system. (In a future post we'll discuss why you never want to allow your project to proceed without some form of Version Control.)

So, what could go wrong? Nothing... unless you have Automated Test Scripts and/or a multilingual project.

Your Automated Test Scripts may fail, since there's a missing period, based on what they were trained to check for. This should cause the QA person in charge to come banging your door down requesting an explanation as to why a change was made without a Change Request.

If you also have a multilingual project, the translation of the original ma…

After the Crisis - preventing the next one

Once a crisis has happens, you usually want to have a post mortem meeting to see how to prevent, or at least be better prepared, for a similar event.
I use the term similar event, for 2 reasons: It's rare that the same identical crisis happens twice You may as well learn as much as possible from the crisis, and use it as a precious learning event Similar to the old saying: "Learn from other people's mistakes, you don't have time to make all of them yourself".  For example, in the sample crisis we discussed - of somebody fainting - you may want to find out who has done first aid courses, and disseminate this information, so that next time somebody faints (or injures themselves) you will know who to shout for.
Analyzing what happens consists of the following steps: Writing up an accurate report of what happened and how it was solved. This can be done by a series of emails exchanges, meetings and/or informal discussions Disseminating this report and getting feedback Have a m…

Crisis Control - introduction

Crisis, as defined by
A highly volatile dangerous situation requiring immediate remedial action.

This can be as trivial as running out of coffee, or as serious as your biggest international customer's database crashing.
Whereas Risk Assessment is the art of preventing a crisis, when a crisis happens, a Project Manager has to know how to take control and remedy the situation in the fastest possible way.
To highlight the difference between Risk Assessment and Crisis Control, let us compare 2 typical scenarios: Risk Assessment: Ensuring the building complies with fire codes: Bright EXIT signs at appropriate places A working sprinkler system Employee awareness of where the fire extinguishers are and how to use them Periodic visits by the fire department to test the systems Company lectures on fire safety Crisis Control: Somebody faints. You don't call a meeting, you don't do a web search, you don't start checking your cellular for a Doctor's number. You immediately sh…

Introduction to Risk Assessment

Risk Assessment is typically done in the planning and design stages of a project.

Risk Assessment is somewhat of a guessing game that pessimists excel at, and consists of making a list of: What could go wrong?

Let's create an imaginary list of potential risks for a project:
A key engineer takes vacationA new component is faulty and cannot be integratedAn earthquake destroys the buildingOnce there's a list of potential things that can go wrong, the risks have to be analyzed, prioritized and tracked.

Analyzing risks.

Typically, each risk is rated on a scale of 1 to 5 for probability and severity using the following rules:

1= low chance of this happening3=there's a 50/50 chance of this happening5=almost sure this will happenSeverity:
1=project will not really be affected if this happens 3=project will be seriously impacted of this happens5=project will fail if this happensTaking our 3 sample risks and scoring them, by multiplying Probability x Severity gives us:

Risk De…

Can a project succeed without a PjM?

Since a Project Manager's task is to ensure the meticulous coordination of projects from inception through to the finishing touches, can't a group of adults manage without one?

The short answer is: "No, they cannot."

There are 3 aspects to this answer:

1. Skill Set

Each person has their skills. Project Managers have skills that other team members do not have - or have not perfected - such as identifying all the required components for the project to be completed, making sure they are all being done in the correct order and ensuring their integration.

Without a Project Manager, a team will arrive at the finishing line only to discover that some crucial aspect of the project has been overlooked.

2. Cheering Squad

For some reason, people perform better when they have an audience.

Twice a year at we collected money for Ezrat Avot. For the past few years I did the collection, starting with an email to the entire company.
Since everybody knew this charity fund, and they…

What does a Project Manager do?

A Project Manager's job description can be summarized as the meticulous coordination of a project from inception through to the finishing touches.

But what does a Project Manager actually do?

I once had a boss who would come by every day at 16:00. The conversation went something like this:
Boss: Today we need to create the following SKU....
Me: Today? It's almost home time. When did you find out about this?
Boss: Yesterday, but it wasn't due until today EOB.

After a few months of this, I realized 2 things:
1. Brilliant engineers who become Team Leaders do not necessarily know anything about planning.
2. I wanted to become a Project Manager and help the company become more efficient.

A Project Manager informs the team of the schedule so that all team members know what to expect in a timely fashion.

Question: Does a Project Manager help with the actual work?

Once I decided to become a Project Manager I went to the CTO and requested to join the PjM team.
Amazingly enough he allowed me to…

What's in a name?

The End Game was chosen as the title for my blog about Project Management, Risk assessment and Crisis Control for a simple reason.

Imagine a tourist returning from Switzerland raving about the amazingly comfortable - state of the art -  tour buses.
When asked what he saw there, he answers that he didn't see anything; he simply enjoyed spending 12 hours a day on those fantastic buses.

A project that doesn't get to the final stages - the end game - and all the way to completion, isn't worth much, unless you're one of those involved in "almost making it happen" and having fun while doing so.

A programmer who wants the experience of coding in a specific language, for example, may not see the problem with an incomplete project.Somebody who comes to work just to get his salary doesn't always care if his project reaches completion.Otherwise, it's obvious why an incomplete project is worthless. Nevertheless, many - some say "most" -  projects (especiall…