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 plans
• Off-site copies of important data
• Distributing your data centers
• Knowing your people's skill sets to be able to replace them and/or switch between them

Each 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 collect
• When to collect data
• How long to store the data
• Know how accurate your data is
• Tracking changes

When everything is going well, the need for data collection is not obvious. When things go wrong, data becomes one of your most powerful tools.

Once you understand the power of your data, you will realize that even when things are going right, you can probably improve them if you analyze the data.

- Danny

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 problem? Because (as we discussed already), Managers hate surprises. Problems and their solutions will affect the schedule, and managers need to be informed of this.

How to make up lost time caused by this problem is another problem; one for which you want to find a solution.

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 on sticky notes. This way tasks can be moved from the "pending queue" to "in progress" to "ready for testing", "in testing" and "ready to deploy".

What is the point of this meeting?

• Status update: Who is falling behind and maybe needs help
• Either help with the current task; shrink the scope, or add manpower or group thinking
• Or else help with the task queue; hand over some future tasks so that the same person isn't an eternal bottleneck
• Schedule update: When does it look like we may be ready to hit the next milestone
• Milestones can also be redefined in real time if needed
• Attendance: Who will be away in the coming days, who is on sick-leave and may need help with outstanding tasks.
• Implementation feedback: informing the team how something was implemented (in 90 seconds) so that good ideas can be adopted team-wide and bad-ideas can be caught early on.

Invariably issues will arise that will take a while to discuss. After about 60 - 90 seconds, the Project Manager should make a note of the issue and then declare let's take this offline.

If needed, a meeting can be called to further discuss the issue. Otherwise, after the meeting has ended, the relevant people can be asked to stay on and finish discussing the issue. This allows most of the people to return to work, while those interested and/or involved can discuss the issue at leisure.

At the next daily stand-up, the conclusion of the meeting should be announced.

At Answers.com we often had 2 or 3 15-minutes stand-ups scheduled one after the other. This forces them to end on time.

After each meeting, the Project Manager must send around the meeting minutes. I used to reply-to-all to the same email every day, with a few updates.

Sometimes sending the same email with today's changes in a different color is effective.

A chart can be used with a new column for each meeting, with a maximum of 4 or 5 days worth of history in the chart at any time.

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 ready will wait for the next (soon to be) release. However, a Master Schedule with best-case guesses is still a good idea, if nothing else so that you have a list of what needs to be done in which order, and to track how far you are from completing the project.

This concept of projects without a deadline will have the side affect of dividing the team in 2:

1. Those who continue to work fast, and always have their part of the project ready as expected. When they miss a self-imposed deadline, they will try catch up the lost time, or apologize.
2. Those who take advantage of the freedom, and see no reason to speed up.

It's obvious which half of the team you will want to replace, sooner rather than later.

- Danny

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 browsers
• If your product is designed for older browsers, it will look really outdated on all browsers
• If your product runs well on newer versions of windows, it won't work at all on old versions; and vice-versa

But 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 it fails gracefully. E.g.: On the web, if you go to an unknown page, you get a 404; you don't break the Internet.

Nicer still is when you customize your 404 page to be friendly.

At some point you have to decide that the system is ready for shipping, even though it's not perfect. It's a Project Manager's job to understand the system well enough so as to help make the call: It's complete even though it's not perfect.

In a future release you can always decide to improve the product to try make it perfect; or you may decide to add more "almost perfect"  additions to it.

- Danny

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, "Is Project Management all about scheduling?"

No! A Project Manager needs to keep track of lots of minor details that people mention by the way.

A Project Manager needs to keep the team focus, and remove distractions, finding other resources (including himself, if needed) to do these.

A Project Manager is responsible for the meticulous coordination of projects from inception through to the finishing touches.

As my sig file at work used to say:

- Danny. Doing. Making it happen, with a smile.

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.
• This way you can have periodic meetings to see if you are behind or ahead of the schedule. While you probably can't do much about it, it will give you the information you need for status reports.

4. It allows everybody to see Dependencies:

• If one piece is dependent on the other being done, the person who will work on on the 2nd piece can do something else meanwhile.
• If the dependency is basically waiting for the same person to finish one task after the next, then maybe adding more people will speed up the project.
• If one piece is taking up a large chunk of time, then maybe it can be broken into smaller pieces - and worked on by many people - or maybe its scope can be reduced for this release.

On smaller projects it often does not make sense to update the schedule. The schedule is simply used as the Master Plan against which you can track and report.

- Danny Schoemann

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 add to it.


Padding:

• When in doubt, simply double the number and add a week. "Many a true word is spoken in jest" aptly applies in this case.
• As a rule of thumb, (based on years of creating schedules,) I believe that 40% of anybody's time is unavailable. Be it vacation, holidays, parties, meetings, sick leave, miluim (as reserve duty is  called in Israel) and other reasons that prevent people from working on their project.
• The estimate you got always assumes they will be working 100% of the time. Always look at a calendar with all local holidays, check the company vacation calendar and speak to the resource in question.
• Even if there's 100% certainty that none of the above will interfere, you still need to add in 20% for the predictably unpredictable.
• An estimate will never include the following, which need to be added:
• Integration - unless your project is a standalone application implemented by a single person. Every milestone will require at least 1 day of integration, unless somebody can prove otherwise.
• Always get these proofs in writing... this will usually prevent the same person from contradicting you next time.
• Testing
• The testing schedule also needs to be padded, as above.
• The testers will usually need time to learn the system, or the changes to the exciting system.
• Debugging
• Testing almost always uncovers bugs that need to be fixed.
• This will affect the engineer's schedule for the next phase of the project.
• This will require another day of testing, at a minimum.
• Documentation
• If needed, then assume it cannot be completed before the debugging stage.
• Maintenance
• Unless the engineer is new (and you allocate for the learning curve) you will have to add padding for them to maintain all the projects they have ever worked on. We have seen cases when senior engineers get no work done because they have a full-time job maintaining years' worth of legacy projects, and assisting (relative)newcomers to learn all the legacy code.

Now you can try create a schedule, which will be out-of-date before you finish preparing it.

In a future post we will discuss how often to update a schedule.

- Danny

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 may be lost. This will either cause an expense to re-translate the sentence, and/or cause the next version to be released with a missing translation.

So now we've learned our lesson, and we first open a Change Request ticket.

Opening the Change Request will take time, as you have to specify where precisely the change is. You will also be notified each time the Change Request changes owners.

The Change Request then will either be assigned to an engineer or a Task Queue. The engineer will eventually stop something she is doing and make your quick fix. Then she will go get a coffee - since she's anyways interrupted - and an hour later she'll be back into her originally scheduled work.

An hour? What was she doing for an hour?

She had to read the Change Request, find the correct file, check-out the latest revision from the Revision Control, make the change, do a Diff on the file to ensure nothing else accidentally was changed, and then Check it back into the Version Control and compile. She then had to assign the Change Request ticket to QA to be tested and the Automated Scripts updated. By now she has completely forgotten what she was working on, and will have to get back into her original project.

QA now has to read and understand the change, update the test plans, sanity check the change to their code and to the product, and assign the Change Request ticket back to you.

That's a lot of time for a tiny change.

If your Change Request also involved changes to the logic or the flow, then you can be almost guaranteed that it will affect something else. This means that besides for a tiny change, the programmer needs to check the overall logic, as well as related functions that may be affected. If the programmer did not think of all possibilities - and adjust them as needed - then QA will open bugs, and then your tiny change becomes a mini-project.

So how do you ensure that as few changes as possible are made? That's where a full Functional Spec with exhaustive Use Cases is useful; more about that in another post.

- Danny

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 meeting to discuss how to prevent a similar crisis from happening in the future
• In a future post we will discuss how to run a Post Mortem meeting.

At no point in time is any specific individual to be blamed or punished for causing the crisis; this will destroy the team spirit and put people on the defensive, instead of working as a team to solve the crisis and prevent the next one.

While you cannot plan for a crisis, you can minimize its impact with some elementary planing:

• Define how to report a serious problem.
• Writing and email or opening a case in the bug tracking system, is not an appropriate way to report a [potential] crisis
• When possible, the person in charge - typically the Project Manager - should be spoken to in person.

• Define who needs to be informed when something goes wrong:
• Your customer
• Your superiors
• Those who will be impacted, either directly by the crisis or by the fact that a team is now trying to solve the crisis
  
• Create a central location for all contact information.
• If possible, multiple ways to contact every single person and company you deal with. Even somebody as "irrelevant" as the cleaning staff could cause a crisis (e.g. by locking the wrong door), or help solve one (e.g. by unlocking a door; they usually have a master key)
  
• Have a list of which skills each person on the team has.
• While you surely know what everybody does on a daily basis, it's useful to know who can be called on in an emergency.
• E.g.: You never know when you will need a paramedic, or somebody who speaks other languages - and you probably have employees who are experts at this but never speak about it.

Carefully planning for the unexpected will greatly reduce the impact of a crisis when it happens - and it will usually happen at the worst possible moment. Why this is will be discussed in a future post.

- Danny

Crisis Control - introduction

Crisis, as defined by Answers.com:

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 shout for help:
• "Call an ambulance"
• "Who is a paramedic?"
• Do elementary first aid

In a development environment, you would typically take the following steps:

• Inform all those who need to be informed
• Call an immediate meeting of all related people
• Discover the scope of the crisis
• Define it's urgency
• Shrink the meeting to a minimum of people
• Create a Tiger Team who will be in charge of the crisis
• The Tiger Team would drop all other work and concentrate on solving the crisis
• The Tiger Team has the authority to use any resources they need

The Project Manager's task should be to walk around from one team member to the next, ensuring they are concentrating on the crisis, escalating issues that are not easily solved, and disseminating frequent status reports.

In a future post we will discuss what to do after a crisis, besides for informing everybody that the crisis is solved, and that everybody should go back to their regular tasks.

- Danny

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:

1. A key engineer takes vacation
2. A new component is faulty and cannot be integrated
3. An earthquake destroys the building

Once 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:

Probability:

• 1= low chance of this happening
• 3=there's a 50/50 chance of this happening
• 5=almost sure this will happen

Severity:

• 1=project will not really be affected if this happens
• 3=project will be seriously impacted of this happens
• 5=project will fail if this happens

Taking our 3 sample risks and scoring them, by multiplying Probability x Severity gives us:

 Risk Description   | Probability | Severity | Score
 1. Vacation        |      3      |     4    |   12  
 2. Component fault |      4      |     4    |   16  
 3. Earthquake      |      1      |     5    |    5 


Prioritizing the Risks

In the above sample, we would first want to deal with Risk #2 as it has the highest score:

A new component is faulty and cannot be integrated

Typically the involved parties would brainstorm how to minimize the risk, and a game plan will be drawn up that will be tracked periodically; every few days if needed.

In this particular case we may decide to start integration and testing of the component ASAP - even before the design is ready, to make sure we have a head start.
In parallel, we may want to do research for alternate solutions as well as a web search to see what issues other people have encountered with this component.
We may also want to have a contingency plan in case we have to deliver without this component; this may involve warning management about this risk and its implications.


We would then tackle Risk #1 as it has the next highest score:

A key engineer takes vacation

Here we we have a high score that is easily solved. Call in all key engineers and ask them about their vacation plans for the duration of the project, and set down clear rules for future vacations, e.g. you need to give us 10 days warning before going on vacation.
In addition, we may want to insist that all engineering work is done in pairs so that no single engineer becomes indispensable. Or we could insist on periodic peer reviews, so that more than one engineer is familiar with each aspect of the project.

 We then look at Risk # 3 - An earthquake destroys the building - and decide that with its low score of 5 we do not have to deal with it. If it should occur we would handle it using Crisis Control, something we will discuss in a future post.


Tracking our risks.

Tracking - as we mentioned - would be done periodically in a quick meeting. The agenda would be:

•  Risk #2: Key component:
• Progress update on integration
• Progress update on search for alternatives
• Status of on-line help
• Risk #1: Key personal
• Present peer-review plan
• Approve vacation schedule
• Remove this risk from next week's agenda
• Did anybody identify new risks?

This meeting would continue until we are confident we have control of the key component that needs to be integrated.

However, a good Project Manager will be continuously be doing a Risk Assessment of the project, until it is safely delivered. This is  done almost subconsciously.


As my good friend and former CTO of Answers.com - Jeff Schneiderman - was wont to say:

Managers hate surprises.

A manager wants to find out that a project may not be delivered on time, as soon as he can, in order to create a contingency plan  and inform relevant parties.


Typically a Project Manager will raise a Red Flag when he suspects the schedule is in jeopardy. Worst case scenario he over-reacted and his suspicions are wrong. As the saying goes:

It's better to be a pessimist; you are continuously either being proven right or pleasantly surprised.

Risk Assessment minimizes the surprise factor in a project - and allows one to use the wisdom of hindsight in advance.

If you ever said "why didn't I think of that" after your project failed, then you need to improve your Risk Assessment skills.

In a future post we will discuss who to brainstorm - a crucial component of coming up with potential risks.

- Danny Schoemann, Jerusalem

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 Answers.com 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 all planned on contributing, one would assume that a simple follow up email closer to the deadline would be sufficient.
However, when I ran a full campaign, with weekly colorful emails and other gimmicks, we collected a lot more money.

Why this is I do not know, but sports teams also seem to perform better when they have a cheering squad and their fans in attendance.

So too, a Project Manager with his constant updates, nudging and encouragement, creates this psychological affect of having people perform better.


3. Coach

One would assume that athletes who are intent on winning would be able to train without any help. Yet most - if not all - pro athletes have a training coach. Somebody who can advise them, cheer them on and provide feedback.

Sports teams also have coaches - some of which are paid a fortune. No self respecting team would dream of trying to win a league without a world class coach.

So too, a winning project needs an experienced and professional Project Manager to to ensure the meticulous coordination of projects from inception through to the finishing touches.


 - Danny Schoemann
  Lecturer and Consultant; Project Management, Risk Assessment and Crisis Control

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 do so, and even gave me a mentor.

The first thing my mentor - Nathan Slonim - taught me was the Golden Rule of Project Management, as he had been taught, when he worked at IBM.

Golden Rule #1: Project Managers do not do any work!

Over the years I have broken that rule various times, in order to help meet deadlines, and the result has usually been that the project spun out of control. You cannot control a project and work on it at the same time.

That said, a good Project Manager knows how to relieve team members of "nuisance work". For example, programmers should not have to do graphic work. A good Project Manager would relieve the programmer of this task, even if it means he has to do some art work himself.

A Project Manager's job is to make sure everything runs smoothly; he cannot afford to be distracted by "tuning out" and becoming part of the project. But he should know the details of what is happening.

In future posts we will address:
- Why do adults need a Project Manager? Surely they can manage without a babysitter?
- Do Project Managers need to understand the technicalities of the project they are managing?
- Is Project Management all about scheduling?
- How do you make an accurate schedule?

Stay tuned.

- Danny Schoemann
  Lecturer and Consultant; Project Management, Risk Assessment and Crisis Control

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 (especially in the software world) do not reach completion.

The End Game of a project is where an expert Project Manager is necessary; somebody who knows how to identify the missing pieces, figure out how to integrate them and get to that magical moment when a project can be called "complete".

In this blog - The End Game - we will be discussing Project Management, Risk Assessment and Crisis Control from various angles, based on my 15 years of experience as a Project Manager, Controller and Coordinator, and my 30 years experience in the Software, Telecommunications and Internet fields. More about that in future posts.