Home Project Management General Practical Project Management A Guide on How to make Projects Work : Part 3
US FTC Compliance
Yes, all these ads are some kind of affiliate link and I get paid a commission if you click or buy.
Not enough to quit my day job, but it keeps the site alive.
- Jeb Riordan, Editor, PROJECTmagazine
A Guide on How to make Projects Work : Part 3 Print
Many projects fail because of the simplest of causes. You don’t have to be a genius to deliver a project on time, nor do you have to be steeped in a mystical project management methodology to be a project manager... We continue the serialisation of A Project Management Primer by our intrepid traveller Nick Jenkins (c) 2005  http://www.nickjenkins.net

 P l a n n i n g

The Purpose of a Project Plan
The purpose of a project plan is to maintain control of a project.
As a complicated process, a project always threatens to exceed the limit of your control. Some people are better than others at controlling complex problems, but all of us reach our limits at some stage. To maintain control you need help in the form of tools and your best tool is your plan.

The project plan controls the project by:

• Breaking a complex process down into a number of simpler components
• Providing visibility for obscure or ambiguous tasks in the project
• Providing a single point of reference for everyone
• Enforcing scrutiny of the sequence and nature of events
• Providing a baseline against which execution of the project can be compared
• Anticipating likely events and providing pre-planned means of avoiding them

A project plan must be as accurate, complete and as specific as possible. How accurate, complete and specific of course depends upon how much time and resources you have.

The Elements of a Project Plan

Every project planning methodology has its own specific taxonomy for its parts. But in a very broad sense the minimum elements a project plan must specify are:

What is to be done – what is desired of the project and what it must deliver to succeed. A high level scope document and requirements specs. at lower levels;

When it needs to be done by– the deadlines by which the objectives must be met, usually in a schedule of some kind;

Who is to do it – The people, sometimes unkindly labelled “resources”, who are to deliver those objectives. This also usually implies costs since the application of costs implies the use of labour. Documented by a project budget;

How it is to be achieved – the method of delivery, covered by documents such as a technical specification, test plans and the like.

Note that you do not need to complete all of these prior to starting your project. Typically one draft of the proposal, schedule and budget are completed before your project commences. Each of the other documents is completed at some later point. Nor should any of these documents be regarded as static or inert manuscripts. Each is a living breathing expression of the project and they should evolve as your project evolves.

Finally, none of these documents has a obligatory size, format or length. I will suggest various forms and styles but they are examples rather than strict templates. Remember, these are tools not doctrine! If it is easier and more efficient to scribble your project schedule on the back of a cocktail napkin then so be it! It is the objective that counts, not the form. The only right form is the one that works for you.

The Fine Art of Scheduling

Why the fine “art” of scheduling?

If it were a science then every project would be delivered on time!

This sadly is not the case. Overruns are so common that most people have no faith in project deadlines. In truth, the art of scheduling is based on experience and the more experience you have, the more accurate your schedule will be. However, you can still produce a good schedule by following some simple rules.

Principles of Scheduling

Rule #1 - Never, give off-the-cuff or unconsidered responses (don't commit to something you can’t deliver).

Scheduling is one part prediction and one part expectation management. If you are pressured into picking a date “on-the-fly” at a random meeting, you can bet that the date will not only be wrong, it will come back to haunt you. A considered response when you have had time to evaluate all the factors is much better. A date picked out of the air is good to no-one, least of all yourself.

More times than I can remember I have sat and watched an inexperienced project manager in a meeting with clients or senior management blurt out a date or like “four weeks from today”. Not one of them to my knowledge ever delivered, it was just a response to pressure, a desire to please.
If management pushes you, give a realistic answer if you have one or ask for more time to formulate a proper estimate – remember it’s your project and you will only be undermining your own success by giving an ‘off the cuff’ response.

Rule #2 - Eliminate uncertainty wherever you can.

The more specific you can be in your project planning, the more accurate your schedule will be. If you leave functionality or other items unspecified in your plan, then you will, at best, only be able to approximate them in the schedule. Don’t go overboard, though, there is a balance. If you are spending time adding detail to tasks which will have no impact on the project delivery date, then you are probably wasting your time.

Rule #3
- Build in plenty of contingency to cope with variation.

No matter how well specified your project and how accurate your schedule, there will be the inevitable random influences that will wreck your carefully crafted schedule. People get sick, equipment fails and external factors join together in a conspiracy to see that you miss your target date. In order to buy yourself some insurance you should build in an adequate amount of contingency, so that you can cope with unexpected delays.

You should spread contingency throughout your project time line and not just place it at the end. If you only have one pool of contingency allocated to the end of your project you are leaving yourself with a large slice of uncertainty. By spreading it throughout your project you allow yourself more options and are able to control the project more closely. You can also “buy back” time when you return unused contingency to the project.

Contingency really refers to the Vth commandment, or “promise low / deliver high”. It is better to be pessimistic in your estimations and then surprise people with a better than expected performance than it is to cut your estimation to the bone and blow your schedule at the first hiccough. The old adage “think of a number and then double it” has some validity when it comes to project scheduling

Rule #4 - Pick the right level of granularity

When drawing up your schedule it is important to pick the right level of detail. If you require daily updates from your team then it makes sense to break into day-by-day chunks. Then everybody has the same understanding of what must be achieved by when.

On the other hand if your project has large portions of time devoted to similar activities, testing for example, then it may be better to simply block-schedule one or two months of testing. Maybe you can leave the details up to your team, it all depends on the level of control you want.

In most projects I’ve dealt with my optimum level of granularity is a week. This means that tasks are scheduled on the basis of the number of weeks they take. Week-by-week is much more comfortable for most people since finishing a task by the end of the week seems more natural than finishing it on a Monday or Tuesday.

Day by day scheduling can provoke more overhead than you really need. If a task is scheduled to be completed on Wednesday but due to difficulties it cannot be completed, it is unlikely that it will be finished on the Thursday, even if a team member predicts it to be so. It is more likely it will overrun by a couple of days and finish sometime on Friday, meaning that subsequent tasks can’t take place until the next week. If I schedule day-by-day then I spend all of my time updating the schedule and not managing the project. On the other hand if I schedule week-by-week it is much easier to cope with such small variations. If something scheduled for “the week beginning Monday the 21st” is delayed by one, two or even three days, then subsequent tasks can either be moved comfortably or may not even be affected at all (depending on my level of contingency).

The only exception to this is where I need to force the pace of a project. I do this by imposing tighter deadlines, to the day or even down to the hour, for completion of tasks. A higher level of control however implies a higher level of attention and if I do this, I know it has implications for my own work-load as well. On a finer grade of schedule I will need to pay closer attention to individual tasks to ensure their completion.

Rule #5 - Schedule for the unexpected

Project management is the art of handling the unknown. Often events and circumstances you could not have foreseen will interrupt the flow of your project. It’s your job to take them all in your stride. Schedule for the most likely delays and cope with them should they arise. If experience or instinct tells you that a certain type of task will overrun, then anticipate it, pad it with some contingency and make sure you have adequate resources on hand when it comes up.

A good way to cope with this is to implement a bit of impromptu risk management (see Risk Management). By anticipating likely risks and prioritising them you will be better able to deal with the unexpected! It also makes a lot of sense to let someone else help assess the risk to your project.

The Format of Project Schedules


If a schedule denotes a sequences of events in time, “milestones” denote the completion of significant portions of the project or the transition from one phase to another. At each milestone there will be “deliverables” which must be completed to move on to the next phase.

As previously discussed, a schedule can include any level of granularity that is reasonably practical. In fact a complex project may involve different levels of scheduling. You might work on a weekly schedule with high level milestones while other team members will have smaller scale schedules with finer grade milestones.

Typically, more detail is involved in projects where there are a number of parallel activities taking place. Where more than one person is working on a project at one time it is obviously possible for these individuals to take on separate areas of responsibility and complete them concurrently. In this case the concept of a critical path comes into play and milestones represent those critical events where ‘branches’ rejoin the critical path of a project.

A Simple Example

In the following example, a simple development project is shown which lists all of its major milestones. The usual cycle of design-develop-evaluate has been concatenated into a single “production phase” which starts on the 22nd of January and is finishes on the 1st of March.


This example is extremely simple and anything more than a one-person project would be unlikely to succeed using this method. The simplicity makes it easy to understand but as a control tool it is not very useful. The extreme high-level of the schedule means that the only indication a project
team will have that a project is not on track is when it misses a major milestone. This could be embarrassing, if not terminal, for the project.

Also there is no contingency scheduled between tasks which could lead to complications or failure of the project to deliver on time. By assuming that everything will run to plan the project are leaving themselves very little room to manoeuvre should anything go wrong.


A More Complicated Example 

In the following, more realistic example, a project is broken down into a number of phases and the start and finish of each phase is recorded separately. Columns have also been added to include the duration of each phase and the deliverables to be completed at the end of that phase.

This new project schedule includes three scheduled iterations of the production cycle of design-develop-evaluate. In reality the three cycles may be many more as prototypes are rapidly produced during the cycle but the schedule imposes a minimum of three cycles. The deliverables for these production cycles are an “alpha”, “beta” and “final” version of the system.


The first thing to note is that the “Duration” column does not exactly match the number of calendar days between the scheduled start and finish dates. This is because the duration column indicates the number of working days between the two dates. For example in 2003, while there are 10 calendar days from the 1st of January to the 10th of January (inclusive) there are only 7 working days due to the fact that the 1st is a public holiday, New Year’s Day, and the 5th and the 6th are a weekend.

The next important point to note is that the phases of the project no longer occur contiguously. That is, there are distinct gaps between some phases of the project. For example between the specification of requirements (which concludes on the 24th of January) and the commencement of the first production phase (on the 3rd of Feb) there are 5 working days unaccounted for. These days are held in reserve by the project as contingency.

In the likely event of things not going to plan, the project can use this contingency to maintain the schedule and original delivery date. If things go exactly to plan the project can simply scrap the contingency and move the schedule forward to the next phase (with subsequent reduction in delivery time). Either way, everyone is happy!

How much contingency to include is a matter of experience. While it can inflate delivery times considerably it can also save the project from damaging and costly failure. In the above example contingency amounts to nearly 50% of the overall production time and represents an excessive amount of caution on the part of the project manager. As a rule of thumb 10-20% is normal, although more is not uncommon. Take as much as you think your project can live with.

One of the problems with contingency is that as soon as people become aware of it they naturally want to use it. Designers, developers and testers will all want to take advantage of the maximum available time to ensure they deliver the best job, even though your schedule may not permit it.

You can’t pretend the contingency doesn’t exist; all of your team will know about it anyway. You have to appeal to their professionalism to avoid intruding on time which is scheduled for genuine emergencies.

One effective but often neglected method of ensuring that contingency remains untouched is to offer success bonuses for on-time delivery or introduce financial penalties for late delivery. The latter often proves unpopular but effective!

Gantt charts

One useful tool available to project managers is a Gantt chart. This is simply a visual representation of a schedule. In a Gantt chart, time is represented along a horizontal axis and tasks listed down the left-hand side. The duration of a task is then represented in the body of the graph by a horizontal bar. Milestones are usually represented by single points or diamonds.
Dependencies between tasks are also shown as linked arrows. An arrow indicates the necessary order of completion for each task and therefore the progress of the project (including the critical path).

gannt chart

In the above diagram you can also note that “Production Phase 1” has been broken down into three sub phases. Delivery of the “core database”, “account screens” and “sales module” have been estimated separately. Together they form the overall estimate for the first production phase and delivery of the Alpha version milestone. Note that either different people are working on the “core database” and “account screens” (since they are happening in parallel) or someone is working overtime!

While this visualisation can be a great help in organising a schedule it should be remembered that the Gantt chart is only a tool. The project manager who constructs the most elaborate and pleasing Gantt chart is not necessarily the one who will complete his project on time. Far too often project managers are lured into the intricacies of artefacts like Gantt charts and spend more time constructing them than managing the project. A Gantt chart helps you design, monitor or communicate a schedule. If it does none of these — then it is simply a useless but pretty toy.

Costing and Budgeting

If scheduling is an art then costing could be considered a black art. Some projects are relatively straightforward to cost but most are not. Even simple figures like the cost per man/hour of labour can be difficult to calculate and in often approximations are used.

Accounting, costing and budgeting are extensive topics in themselves and I will not attempt to cover all of them here. Instead we will focus on the specific application of costing and budgeting to projects and attempt to give you a grounding in the necessary terminology and principles.

Some fundamental principles to keep in mind are derived from accounting practices:

• The concept of 'prudence' – you should be pessimistic in your accounts (“anticipate no profit and provide for all possible losses”).Provide yourself with a margin for error and not just show the best possible financial position. It’s the old maxim: promise low-deliver / high once again
• The 'accruals' concept- revenue and costs are accrued or matched with one another and are attributed to the same point in the schedule. For example if the costs of hardware are in your budget at the point where you pay the invoice, then ALL the costs for hardware should be “accrued” when the invoice is received.
• The ‘consistency’ concept. This is similar to accruals but it emphasises consistency over different periods. If you change the basis on which you count certain costs you either need to revise all previous finance accounts in line with this or annotate the change appropriately so people can make comparisons on a like-for-like basis.

Note that the principles are listed in order of precedence. If the principle of consistency comes into conflict with the principle of prudence, the principle of prudence is given priority.


At a basic level the process of costing is reasonably simple. You draw up a list of all your possible expenditure and put a numerical value against each item; the total therefore represents the tangible cost of your project. You may also however need to consider “intangible” items.

Tangible costs

• Capital Expenditure – any large asset of the project which is purchased outright. This usually includes plant, hardware, software and sometimes buildings although these can be accounted for in a number of ways.
• Lease costs – some assets are not purchased outright but are leased to spread the cost over the life of the project. These should be accounted for separately to capital expenditure since the project or company does not own these assets.
• Staff costs – all costs for staff must be accounted for and this includes (but is not limited to):
salary and pension (superannuation) costs; insurance costs; recruitment costs; anything which can be tied directly to employing, training and retaining staff.
• Professional services –all large-scale projects require the input of one or more professional groups such as lawyers or accountants. These are normally accounted for separately since a close watch needs to be kept upon expenditure in this area. Without scrutiny the costs of a consultant engineer, accountant or lawyer can quickly dwarf other costs.
• Supplies and consumables – regular expenditure on supplies is often best covered by a single item in your budget under which these figures are accrued. They are related to overhead below.
• One-off costs – one-off costs apply to expenditure which is not related to any of the above categories but occurs on an irregular basis. Staff training might be an example. While it might be appropriate to list this under staff costs you might wish to track it independently as an irregular cost.
The choice is yours but the principles of prudence and consistency apply.
• Overheads – sometime called indirect costs, these are costs which are not directly attributable to any of the above categories but never-the-less impact upon your budget. For example it may not be appropriate to reflect the phone bill for your project in staff costs, yet this still has to be paid and accounted for. Costing for overheads is usually done as a rough percentage of one of the other factors such as “staff costs”.

Intangible costs

It has become fashionable to account for “intangible” assets on the balance sheets of companies and possibly also projects. The argument goes like this: some contributions to a project are extremely valuable but cannot necessarily have a tangible value associated with them. Should you then account for them in the budget or costing? The “prudence” principle says yes but practicality says “no”. If you are delving this murky area of accountancy you should seek professional help and advice.

Typical things you might place in the budget under intangibles are “goodwill” and “intellectual property”. Personnel-related figures are a frequent source of intangible assets and so you might find things like “management team”, “relationships” and “contacts” on an intangibles balance sheet.


Once you have costed your project you can then prepare an appropriate budget to secure the requisite funds and plan your cash flow over the life of the project. An accurate cost model will of course entail a fairly detailed design or at the very least requirement specification so that you can determine your scope of work. This is normally completed well into the design phase of the project.

The sad truth of the matter however is that more often than not you are required to prepare some sort of indicative budget before approval of the project — and you are often held to your original estimates. You must be extremely careful with initial estimates and always follow the “promise low / deliver high” commandment.

Costing and budgeting follow the iterative life cycle as do other tasks within the project. As you refine your design, so you will need to refine the costing which is based upon it.

As in scheduling, you need to build in adequate contingency (reserves) to account for unexpected expenditure. For example, if due to a failure in the critical path a task is delayed and a milestone (like software purchase) falls due in the month after it was scheduled. This can wreck your carefully planned cash flow. But if you have carefully budgeted your project then variations should be relatively easy to spot and cope with as they arise.

Just as in scheduling you should have regular budget reviews which examine the state of your finances and your expenditure to date and adjust the planned budget accordingly.

Risk Management

Risk management is one of the essential phrases in project management these days so I’m going to go out on a bit of a limb when I suggest that it’s actually not that important. Understanding the concepts of risk management will be useful for you but I have rarely, if ever, seen it used properly.

The basic concept of risk management is a “chicken-little” assessment of the project which identifies anything significant that could possibly go wrong with the project. A risk management plan will then seek to mitigate or eliminate those risks, hopefully avoiding their consequences.
Normally project managers and business managers use it as a kind of 'code' to describe when the project has stuffed up. “We're going to mitigate this risk!” they say as the deadline slips away.

One of the best uses of risk management is to have a “risk” item in your regular project meetings to highlight to everyone the risks that the project currently faces.

Risk Management Officer

One way for larger-scale projects to control their risk is to appoint a risk management officer. The risk management officer’s responsibility is to identify all the risks to a project and to prioritise and present them to the project team for resolution. In smaller-scale projects, risk management is often intrinsic to the role of the project manager and is not considered separately. The principles outlined in this section can still be utilised by smaller project teams, however. Rather than appointing a separate risk management officer, a discussion of likely risks can simply be added to whatever regular team meetings occur. A quick discussion amongst different representatives of the team can often highlight some interesting items which have been concealed from the rest of the project team.
The formalised process of profiling and resolving risks can then be applied in an informal manner to plan for potential threats to the project.

Risk Profiles

Risk to a project can be measured on two major axes: likelihood of failure and impact of failure.

The more likely a problem is to occur, the more risk it poses the project. Even fairly minor problems or issues can become a threat to the project if they occur so frequently that they can’t be avoided.
Similarly, the impact or consequences of a problem are also important. Some problems can stop a project in its tracks all by themselves.

Many systems exist for categorising risks into different categories but the one presented here is fairly simple. In this system each risk item is qualified on two scales: likelihood and impact. Each scale is divided into two categories of “low” or “high” and risks are rated according to each scale.

riskA “critical” issue represents one that will stop the project in its tracks (known as a “show stopper”) and must be dealt with immediately. “Major” risks represent a significant threat to the project because of their frequency or because of the seriousness of their impact; these threats usually have to be dealt with as soon as possible. The third category of risks are “minor” risks which are neither likely nor particularly serious and can be left until others have been dealt with. Minor risks however have an annoying habit of turning into major ones when your back is turned.

Resolution of risks

Once you have profiled your risk they can be ranked into an ordered list representing the various threats to the project to be dealt with. The more significant can then be examined and assigned an action by the project team.

Typical actions are:

Research the risk is not yet fully understood. Its impact or likelihood of occurrence may be unclear or the context in which it may occur could seem unreasonable. Further research by members of the project team is warranted.

Accept the risk is unavoidable and must be accepted as-is. This category of risks become extremely important to a project since they cannot be resolved but still represent a threat to completion. Anticipation therefore become the key to dealing with this category of risk.

Reduce the risk as it stands is unacceptable. The project team must act to reduce the risk and to establish contingency plans should the risk occur. The risk will have to reviewed in future to define the threat it poses.

Eliminate the risk is unacceptable under any circumstances and must be eliminated as a possibility. The project team must put in place processes and procedures not only to ensure the immediate threat is eliminated but that it does not re-occur in the future.

Recording risks

The simplest way of recording risks is with a table or spreadsheet that lists the risks and their priorities. This can then be regularly reviewed by the project team and action taken appropriately to mitigate or eliminate those risks.

Below is an example of a sample risk table for a project:


In the above table, failure by suppliers to deliver some components has been rated as a minor risk.
This sort of judgement can only be made on the basis of experience and within the context of the current project. If the supplier is well known and trusted, then the likelihood of them delivering late is likely to be low and hence the risk can be classified as minor.

Labelling scheduling as a critical area of risk is also an outcome of experience. If previous projects of a similar nature have run-over due to scheduling problems then it is highly likely that this project will suffer a similar problem. Here, too, you can see the benefits of having a separate risk management officer since it is unlikely a project manager, however honest, would rate his own scheduling abilities as “high” risk.

Change Management

A project of any significant length will necessarily deviate from its original plan in response to circumstances. This is fine as long as the change is understood. If the change is not managed but is happens at a whim, it is no longer a project, it’s anarchy!

Change management is a way of assessing the implications of potential changes and managing the impact on your project. For example a change in client requirements might mean a minor fix or it might mean a complete re-write of the design. Change management gives you a process to evaluate this and introduce the change in a controlled fashion.

Since change is inevitable you need a fluid way to handle the inputs to your project. It is important that the inputs to your project, your requirements and your design, are able to handle change and evolve over time. If your inputs are static, unchangeable documents then you are going to be hamstrung by their inability to keep pace with changing circumstances in your project.

The most important aspect of change control is to actually be able to know what has changed.
On one product I worked with 30 or more programmers and there was no real change control.
Every day the programmers would check in changes to the software and every night we used to run mammoth automated tests, processing 1.5 million data files and producing about 500 lines of test reports.
One day we’d come in and find that our results had improved 10-20% overnight. The next day we’d come back to find the product had crashed after the first thirty minutes and was unusable.
The problem was we didn't know who or what was responsible, there was no change control.
Eventually we implemented a system and were able to make solid progress towards our goals.

Change Management Process

The basis of change management is to have a clear process which everyone understands. It need not be bureaucratic or cumbersome but it should be applied universally and without fear of favour.
The basic elements of a change process are :

• What is under change control and what is excluded ?
• How are changes requested ?
• Who has the authority to approve or reject changes ?
• How are decisions upon approval or rejection are documented and disseminated ?
• How changes are implemented and their implementation recorded ?

The process should be widely understood and accepted and should be effective without being bureaucratic or prescriptive. It is important for the project team to be seen to be responsive to client needs and nothing can hurt this more than an overly-officious change control process. Change is inevitable in a project and while you need to control it you do not want to stifle it.

A typical process might be as minimal as the following:

1. Once a project document has been signed-off by stakeholders, a change to it requires a mandatory change request to be logged via email. The request will include the nature of the change, the reason for the change and an assessment of the urgency of the change.

2. A “change control board” consisting of the development manager, test lead and a product manager will assess the issue and approve or reject each request for change. Should more information be required a member of the change control board will be assigned to research the request and report back.

3. No change request should be outstanding for more than a week.

4. Important or urgent requests should be escalated through the nearest member of the change control board.

5. Each change which is accepted will be discussed at the weekly development meeting and a course of action decided by the group. Members of the development team will then be assigned to implement changes in their respective areas of responsibility.
If you have a flexible change request process team members can be encouraged to use it to seek additional information or clarification where they feel it would be useful to communicate issues to the whole project team.

Tracking Change

To make change management easy you need a simple method of tracking, evaluating and recording changes. This can be a simple database or log but in large projects it has evolved into an customised information system in its own right.

As such the system needs to be able to handle:

• Logging requests for changes against products and documentation
• Recording and managing the priority of a particular change
• Logging the decision of a change management authority
• Recording the method and implementation of change
• Tracking implemented changes against a particular version of the product or document

The more structured a system the more secure the change control process, but obviously the more overhead. A balance must be struck between the enforcement of proper procedure and responsiveness of the system.

Change management systems are useful for managing everyone’s expectations too. Often decisions are requested by stakeholders or clients and if proper consultation is not entered into they can sometimes assume they will automatically be included (just because they asked for it).

If the volume of change requests is particularly high (as it often is) communicating what’s in and what’s out manually can be difficult. A simple, well understood change management system can often be directly used by stakeholders to log, track and review changes and their approval. This is particularly true for projects that span disparate geographical locations where meetings may not be possible.

In many projects the change management system can be linked to (or is part of) a defect tracking system. Since resolution of a defect is, in effect, a request for change both can often be handled by the same system. The change and defect tracking system can also be linked with version control software to form what is commonly known as a Software Configuration Management (SCM) system. This integrated system directly references changes in the software against specific versions of the product or system as contained in its version control system. The direct one-to-one reference cuts down on management overhead and maintenance and allows the enforcement of strict security on allowable changes.


End of Part 3 of A Project Management Primer

Nick Jenkins (c) 2005


About the Author:

Nick Jenkins is an IT manager with experience in software development, testing and project management. He started his working life as a software developer in Perth, Australia, where he helped author a book about educational software. He had is first management role Sydney where he helped establish the Access Testing Centre (ATC). Since then he has has worked in London, Boston and Sydney for companies like the address management specialist QAS Ltd, enterprise security firm ISS Inc. and the telco giant Singtel-Optus. Now he is living and working Prague in the Czech Republic where he is trying to learn how to speak Czech, drink slivovice (plum brandy) and ice skate.

Go to Part 1
Go to Part 2
Go to Part 4
Go to Part 4

Comments (0)Add Comment

Write comment
bold italicize underline strike url image quote Smile Wink Laugh Grin Angry Sad Shocked Cool Tongue Kiss Cry
smaller | bigger

Copyright © PROJECTmagazine (c) 1998 - 2019 for practical project management information. All rights reserved.