Mariusz - Manage

TED Talks

2010-01-29T23:04:00.002+01:00

Daniel Pink on the surprising science of motivation

Zig Ziglar - Attitude Makes All The Difference

2009-11-17T18:27:00.001+01:00

Goals: Very simple but so difficult for some people.

Who The Expeirenced Project Manager Is

2009-07-07T17:47:00.007+02:00

It is how I see who the PM is… enjoy

• PM is a person who should never be surprised, but he usually is… (Otherwise his job is extremely boring)
• PM is a person who should never complain, because it means that he is not enough experienced
• PM is a person who must successfully finalize the project and nobody really cares how he did it.
• PM is a person who delivers projects in a way to make as many stakeholders as possible happy with it.
• PM is a person who always works in a “difficult environment” (at least he believes in that :) )
• PM is a person who knows the best how the process in the company should looks like, but for some reasons his organization usually supports different methodology
• PM is a person who knows that expression “successful project” has many meanings
• PM is a person who knows that triangle cost, resources, and scope is too easy to be truth and everybody always expects that corners can be changed independently.
• PM is a person who says about the scope “it is difficult” instead “not possible”
• PM is a person who says about the time “it is aggressive” instead “not possible”

Eli Goldratt

2008-05-17T22:54:00.009+02:00

Coherent set of good advices.... but not only....

Viable Vision – a few words about.
Web cast by Eli Goldratt.

It’s all about contributing something

2008-05-16T09:26:00.001+02:00

Benjamin Zander - look at the passion!

Following the ninth

Learning from leaders

2008-02-14T23:39:00.005+01:00

Search Leaders for career hints.
Just jump and read recent tips from Leaders.
Someday I will find the time to read them all...

Career - Working in Europe

2008-02-14T23:29:00.002+01:00

Compendium of knowledge about the European job market.
There are information about culture differences, key industries, labour market, application methods and cost of living.

Project Management Career Path

2008-02-14T23:16:00.002+01:00

In general it is truth, however I do not fully agree with the all the points.

Mind mapping

2008-02-14T22:50:00.005+01:00

FreeMind
Free mind mapping software. Very useful tool!
Mindmeister
Online mind mapping tool. Nice Idea for student’s projects.

Mind mapping Wikipedia
Much more mind mapping software propositions are there.

Chain Theory in Business

2008-02-14T22:42:00.001+01:00

It is quite interesting idea. I have never met the real situation in which it has been used but it may work. On the organization level it may be very difficult to slow down hundreds of people to achieve necessary speed. Usually we are trying to speed-up the some parts of the system to keep it moving. Any comments? (experiences?)

Dealing with difficult people

2008-02-13T21:56:00.000+01:00

A few possible scenarios in situations with some peoples.

Leadership

2008-01-30T21:20:00.000+01:00

Some time ago I was on Leadership training organized in my company.
Our trainer showed us a something at the end.
Enjoy!

Youth is not a time of life - it is a state of mind, it is a temper
of the will, a quality of the imagination, a vigor of the emotions, a
predominance of courage over timidity, of the appetite for
adventure over love of ease.

Nobody grows old by merely living a number of years;
people grow old only by deserting their ideals.
Years wrinkle the skin, but to give up enthusiasm wrinkles the soul.
Worry, doubt, self-distrust, fear and despair -
these are the long, long years that bow the head and
turn the growing spirit back to dust.

Whether seventy or sixteen,
there is in every being's heart the love of wonder,
the sweet amazement at the stars and starlike things and thoughts,
the undaunted challenge of events, the unfailing childlike appetite for what next,
and the joy and the game of life.

You are as young as your faith, as old as your doubt;
as young as your self-confidence, as old as your fear,
as young as your hope, as old as your despair.

So long as your heart receives messages of beauty,
cheer, courage, grandeur and power from the earth,
from man and from the Infinite,
so long you are young.

When the wires are all down and
all the innermost core of your heart is covered
with the snows of pessimism and the ice of cynicism,
then you are grown old indeed and
may God have mercy on your soul.

Samuel Ullman

Why people leave organizations

2008-01-09T19:22:00.001+01:00

I have found a list of 10 reasons why the people leave organizations by Gautam Ghosh. These 10 things are really dangerous in our work.

SWANSON'S UNWRITTEN RULES

2007-11-11T00:12:00.000+01:00

William Swanson, Chairman and CEO of Raytheon Corporation, spent his entire career at Raytheon, and was later asked if he could put his rules down on paper. So he did: in 3-inch-by-5-inch spiral-bound notebooks handed out to executives and customers.

For those of you who haven't seen them, here they are for your review:

SWANSON'S UNWRITTEN RULES

1: Learn to say, "I don't know." If used when appropriate, it will be used often.
2: It is easier to get into something than to get out of it.
3: If you are not criticized, you may not be doing much
4: Look for what is missing. Many know how to improve what's there; few can see what isn't there.
5: Presentation rule: When something appears on a slide presentation, assume the world knows about it and deal with it accordingly.
6. Work for a boss to whom you can tell it like it is. Remember, you can't pick your family, but you can pick your boss.
7: Constantly review developments to make sure that the actual benefits are what they were supposed to be. Avoid Newton's Law.
8: However menial and trivial your early assignments may appear, give them your best effort.
9: Persistence or tenacity is the disposition to persevere in spite of difficulties, discouragement or indifference. Don't be known as a good starter but a poor finisher!
10: In doing your project, don't wait for others; go after them and make sure it gets done.
11: Confirm the instructions you give others, and their commitments, in writing. Don't assume it will get done.
12: Don't be timid: Speak up, express yourself and promote your ideas.
13: Practice shows that those who speak the most knowingly and confidently often end up with the assignment to get the job done.
14: Strive for brevity and clarity in oral and written reports.
15: Be extremely careful in the accuracy of your statements.
16: Don't overlook the fact that you are working for a boss. Keep him or her informed. Whatever the boss wants, within the bounds of integrity, takes top priority.
17: Promises, schedules and estimates are important instruments in a well-run business. You must make promises — don't lean on the often-used phrase: "I can't estimate it because it depends on many uncertain factors."
18: Never direct a complaint to the top; a serious offense is to "cc" a person's boss on a copy of a complaint before the person has a chance to respond to the complaint.
19: When interacting with people outside the company, remember that you are always representing the company. Be especially careful of your commitments.
20: Cultivate the habit of boiling matters down to the simplest terms: the proverbial "elevator speech" is the best way.
21: Don't get excited in engineering emergencies: Keep your feet on the ground.
22: Cultivate the habit of making quick, clean-cut decisions.
23: When making decisions, the "pros" are much easier to deal with than the "cons." Your boss wants to see both.
24: Don't ever lose your sense of humor.
25: Have fun at what you do. It will be reflected in you work. No one likes a grump except another grump!
26: Treat the name of your company as if it were your own.
27: Beg for the bad news.
28: You remember 1/3 of what you read, 1/2 of what people tell you, but 100% of what you feel.
29: You can't polish a sneaker.
30: When facing issues or problems that are becoming drawn-out, "short them to the ground."
31: When faced with decisions, try to look at them as if you were one level up in the organization. Your perspective will change quickly.
32: A person who is nice to you but rude to the waiter, or to others, is not a nice person. (This rule never fails).
33: Never be afraid to try something new. Remember, an amateur built an ark that survived a flood while a large group of professionals built the Titanic!

There is one common part of the all rules list I have ever read.
Usually, you need to experience difficult situations in your life (or be trained through experience) to understand some of the rules from list like this.

Open source PM tool - OpenProj

2007-11-10T23:43:00.003+01:00

I didn’t have a time to check it by myself; so there is only photo and Jack Dahlgren opinion:

It is free
Look and feel similar to Project (maybe too similar... but let the lawyers decide)
File compatibility
Ability to edit and create schedules
Cross-platform compatibility (Mac users will rejoice after being denied the latest versions of Microsoft Project)

See his article about it.
OpenProj Page(download)

Strengths-Based Thinking & Application - Marcus Buckingham

2007-11-09T23:14:00.000+01:00

Set of rules about good leaders from Marcus Buckingham.

The chief responsibility of a manager is to turn a person’s talent into performance.
Great managers find what is unique about each person and capitalize on it.
Average managers play checkers while great managers play chess - they understand the differences in each piece and coordinate the team to take advantage of the individual strengths.
Great managers spend 80% of their time working to grow an employee’s greatest strength.
Great leader’s rally people to a better future.
Great leaders find what is universal and capitalize on it.
Great leaders muse, pick heroes with great care, and practice their words, phrases, and stories.
Great leaders answer these questions: Who do we serve? What is our core strength? What is our core score? What actions can we take today?

Video - Strengths-Based Thinking & Application - Marcus Buckingham

TED Talks: Richard St. John: Secrets of success in 8 words, 3 minutes

2007-11-09T22:14:00.000+01:00

No comments :)

7 Habits of Highly Ineffective Managers

2007-11-09T21:06:00.000+01:00

Slacker Manager guru Phil Gerbyshak has a humorous management post called "7 Habits of Highly Ineffective Managers." Here are my favorites:

Responsibility without Authority
Assign people a responsibility, tell them that they are responsible for the outcome, and then don’t give them anywhere even close to sufficient authority to make it happen. Perfect for those budding superstars who are threatening to take your job.

Set it and forget it!
I like to call this “Ron Popeil on management.” Delegation is for sissies, just throw out the task and let them guess on how you want it done. Especially effective if you never check in on their progress, and then demand it be “done right the first time.”

Great Expectations? How about NO Expectations?!?
Setting expectations is for sissies! Don’t tell your team what you expect of them, and then hold each of them to an imaginary, and completely random, standard, marking their review full of red ink. After all, if they don’t know what you want them to do, they can’t possibly do it!

Fight Fires, Don’t set priorities!
Give someone on your team a project. Don’t tell them how important it is. Keep throwing more little balls at them until they drop the big one. Complain about how they have no idea what’s really important to you. Continue until they cry or quit, whichever comes first.
Do the same thing with projects you get. Focus on the urgent, forget the important, and keep fighting those fires!

Read the whole article: 7 Habits of Highly Ineffective Managers

Tony Robbins motivation: TEDTalks

2007-09-10T22:27:00.001+02:00

Just watch this video. No comments needed.

Money and motivation

2007-08-27T21:36:00.000+02:00

It has been repeatedly proved that money is only one of the possible motivators (and probably not the best one).Nevertheless, it would be good to increase our people’s motivation when giving them bonuses.

Let’s think what we can do?

Give all people almost the same bonus, only differentiating them slightly
Reward the best and leave the rest
Distribute the money on the basis of the Gauss curve
Should we give bonuses to people involved in a project which is still in progress or only when the project is completed? What about very long projects? (2 years)
Should we give all the money only if the project was 100% successful, and only smaller bonuses if the project was e.g. delayed.
Should the bonus amount depend on the commitment and performance? How do we measure them?
What is the minimum size of the bonus which still motivates people to work better? Is 5% of a month salary once in a year enough to motivate?

Of course there is no simple answer. It always depends…

What does an individual engineer think about the bonuses he or she receives? This depends on his/her particular situation and expectations and cannot be generalized.

What does a group of people (team) think about the bonuses? It depends on the overall atmosphere in the organization and common engineers’ expectations of the management. Needless to say we never have enough money to satisfy everyone, but the point is how many people will be disappointed.

What do we usually do?

The standard way is to create some KPIs to measure the performance. Then based on them, use a sophisticated methodology (not to miss anybody) to calculate bonuses for all team members. Another option is to give most of the money to well known “best performers”.

A few weak points…

Local Stars creation – An engineer, who saved the project by fixing a critical error at a crucial moment surely deserves a bonus. We remember him very well. But what if the problem was known to him, yet not fixed earlier? Maybe our “star” is rather an idler who doesn’t control his working area. It may happen that we have more “stars” like this in our team. Should we reward them by giving bonuses?
A different example is an engineer who always does his job well performing even difficult or unpopular tasks without complaint and creating a very low amount of new problems. Usually we do not pay attention to such a person, and do not remember about him at the time of giving bonuses. Our incentive system should be able to reward and motivate such people as well.
Another problem is a difference in competences and/or commitment between engineers. There are people who can quickly solve even a very difficult issue, but are not fully committed to the project. (in matrix organizations some engineers can be involved in several projects simultaneously).There are also people who engage in the project 200% and are ready to work overtime, but their real effectiveness is rather low. How will our system deal with such cases?

How do we get money to motivate people to work efficiently? (Of course, keeping in mind that money isn’t the best motivator)

In my opinion one of the most important things is not to create complicated and formal incentive systems.
People tend to calculate, how much money they should get in each project. This means heading for disappointment after they check their bank account. People may also (unconsciously) tend to manipulate their key performance indicators to get better bonuses.

The truth is that when evaluating engineers we usually rely on our own observations and subjective opinions. Even a sophisticated incentive system with many KPIs usually needs to be “adjusted” manually by the management because not all aspects of work can be precisely measured.

If so, maybe it is better to make it clear from that the final decision is always at our discretion.

Bonuses should also be adjusted to general expectations of engineers in our organization. It should not happen that people are given high bonuses while all projects are delayed, or conversely, that bonuses are much lower than expected even though all projects have been developed on time.

Bonuses should not only reflect individual engineers’ commitment but also a wider context of their work as well as personal expectations. It is good to talk with all team members separately and to give them opportunity to present their success and describe their involvement and expectations. Such information can allow us to better fit the incentive to the employee.

Of course it is not possible to make everyone happy and there will always be some unhappy engineers. Our task is to make this group as small as possible and motivate the potentially unhappy by using other motivation techniques.

Trying to motivate people with money alone is a quick road to failure.

The process creation process

2007-08-07T21:16:00.000+02:00

I was recently asked to create a process for my organization. As I developed it I began pondering on the process as such. By itself, a process is simply a formalized idea to systematize a part of the organization.

It is a principle to be followed by all concerned employees, resistant to manipulation attempts yet flexible enough neither to disrupt normal job activities nor to generate extra work.

In fact all employees might be doing the right thing on their own accord without referring to a formal process. It should be enough to make their duties known to them verbally.

It “should” be but what if it isn’t?

A process helps us set measurable and verifiable standards for the ways things are to be done, enforcing employees’ proper behaviors. And so if Mr.Smith fails to do his duties in accordance with the process provisions a verifiable trace will remain in the system.

On the other hand, we don’t want to create too much additional work or the process will become an unwanted chore opposed by all the staff. Conversely, well designed and well executed processes will be appreciated by most employees since they can improve their sense of security owing to more predictable environment which Maslow believed to influence their motivation level.

The process flexibility and the openness to unexpected occurrences invite special attention. The process user must not be faced with inability to do what is obvious but has not been provided for in the process.

Thus the creation of a process is in itself an excellent test for its maker.

Bugs life – test management

2007-07-30T21:05:00.000+02:00

Communication is decisive in the whole project managing process. In case of test management it can vital for the product quality and the realization time.

Intra-organizational tests

Effective test performance requires interaction between the team of engineers who submit the product for testing and the quality assurance (QA) team who test it.

In the process, engineers tend to shift part of their job onto the QA team by performing only basic tests of developed solutions, resulting in lots of petty defects concerning individual modules.

On the other hand the QA team tends to verify the defects only roughly and avoid detailed description for the problems reported to the system making them difficult to be reproduced by engineers.

Good communication on this level saves both sides a lot of time by solving these problems and helping to understand the scope of changes introduced into the project and bound for testing as well as the scope of planned or completed tests.

Extra-organizational tests

The case is different with tests carried out outside of the organization e.g. by the client. To fix the bugs reported from outside it is necessary to reproduce them in the test environment within the organization. Unfortunately most failure descriptions which reach us are limited to a few words and the clients hardy ever know what is a ”reproducibility path”, “initial state”, “expected behavior” or “reproducibility level”.
Obtaining all these data (with or without the client’s help) consumes a lot of QA time and resources.

Communication with the client on this level is essential so it is worthwhile investing some time in the presentation of the failure lifecycle and making the client aware how the quality of bug description influences the repair time. (Unless summary description is indeed intended!)

Quality management

Product quality management usually means estimating the risk of subsequent failures after the execution of a particular set of tests. Notably doing the whole set of test-cases doesn’t guarantee the quality of the product.

Neither can the quality of our product determined by the number of bugs detected without considering the test conditions. Small number of bugs can be result of either their actual absence or hurried and imprecise performance of the tests.

Reduced number of tests due to delivery of incomplete functionalities also affects the quality of performed tests, and results in lower reliability of the product.

The key to success is good communication with the QA department which should be actively involved in the planning of both the scope and duration of the tests. This allows for optimization of the effort needed to ensure the required product quality level.

I hope your dialogs with QA are like this:
QA: „We have found one more critical issue in your project”
PM: “It is good to hear it. We have enough time to fix it and verify it in the next test cycle”

Teamwork – how to motivate our team

2007-07-15T17:38:00.000+02:00

Most of the articles I have read about motivation answer the question:
“What to do to motivate our people to work more effectively”.
It is a very important question, but I believe an even more important question is:
“What makes people lose their motivation?“

The first thing which happens usually is absence of trust in the team. Some of our people do not feel so comfortable speaking their mind in front of the group. Ask yourself:

How many of our people do not cooperate very well with the rest of the team and why?
Do we have “informal groups” in our team?

Sometimes the answer is “yes” and we can just observe some people trying to “avoid conflict” and not participating in the discussion. They just do not want to carry the conflict from professional to private life. After a while we may even notice that some people do not share the knowledge they have even if it is crucial for the project. As a result, instead of having “the best solution we were able to generate” we have “just a solution”

After some time people who cannot share their opinions with the team stop participating in the making of decisions and consequently in their realization. We end up having „team” members who work at the minimum of the capabilities and do not think about the common goal anymore. They start to go about their own goals neglecting the team needs.

The realization of the team original goal becomes more and more difficult and the team itself resembles a random bunch of individuals rather than a regular project team. In such conditions the team cannot achieve great success and the demotivating atmosphere may spread on other project groups.

The problem boils down to five points:

Absence of Trust --> Lack of team bond
Fear of Conflict --> Fake harmony
Lack of Commitment --> Insecurity
Avoidance of Accountability --> Low standards
Inattention to Results --> Focus on status and ego

What to do in this situation?

Instead of trying random motivating tools such as bonuses/rewards, try to address the root of the problem by building on mutual trust and working to solve problems as they arise. Unfortunately it takes some time but in the long run it brings substantial benefits in the form of well functioning team able to face upcoming challenges.

Depending on the problem, we can do the following, according to Patrick Lencioni advice given in the „The Five Dysfunctions of a Team”:

The Role of the Leader…

Absence of Trust --> Be Vulnerable
Fear of Conflict --> Demand Debate
Lack of Commitment --> Force Clarity and Closure
Avoidance of Accountability --> Confront Difficult Issues
Inattention to Results --> Focus on Collective Outcomes

More information can be also found in numerous publications including: Patrick Lencioni

Just the world

2007-07-05T23:08:00.000+02:00

Programmers’ efficiency - practical hints

2007-06-24T17:23:00.000+02:00

Just waiting and wasting your time…? Sometime it is more than just a time waste.

Let’s see how much time is required to fully compile and build our projects. I am pretty sure that in most cases the time will be considerable. Such factors as project size, external components, dedicated builders, pre-compilation tools and simple engineer’s mistakes in header files (*.h) may incredibly increase the compilation time.

Usually we put some effort into optimizing it to reasonable limits to avoid wasting our engineers’ time, but do we really know what the “reasonable limit” is?
What is the maximum time the engineers should be allowed to wait?

Not very long!

At some point we start to waste more than just “compile time”: we start wasting our people’s efficiency.

How it works
The engineer who is working on his/her module and is not able to compile and check results of his work immediately (3-5 minutes) starts trying to prevent wasting time.

What can he do?

Dry implementation – Engineer is trying to implement his part of code all at once by writing hundreds of lines of code without checking it step by step. Series of tests done by the engineer afterwards usually do not cover all the implemented code lines. After a few successful tests, the engineer usually assumes that his produce works well, and closes the task, possibly leaving some changes unchecked.
A few issues at once – Engineer is trying to implement as many aspects of the fix as possible for each build. After the long compilation it often happens that he does not remember all implemented improvements and leaves something out during the tests.
Let’s do something else – while the build is pending, the engineer has plenty of time to do different things like another task, another coffee, phone conversation or web browsing. The problem is that very often he simply misses the moment when compilation is over; he is also distracted, forgetting all about the things which he needed to check when the build is completed.

It is easy to imagine that such a “smart” engineer will generate low quality source code which needs to be corrected later.

Let’s calculate
Assume that we have reduced the compilation time from 10 to 5 minutes.

Considering only profits related with pure “compile time”, a single engineer can save about 1hour a day which means that they are 15% more efficient and we save 15% on their salaries. In few months all expenses related to reduction of compilation time are refunded.

Not only “compile time”
The most profitable part of this optimization has to do with the engineers who can now stay focused on the work and not be distracted by other things in the meantime. I am pretty sure that this is worth much more than the money in the calculation above.

5-Steps to Project Success (Seriously!) v1.1

2007-06-13T20:50:00.000+02:00

It is all truth about Project Management.
Check also Principle Based Project Management

GanttProject

2007-05-27T23:14:00.000+02:00

GanttProject is a free tool similar to MS Project and able to import/export MS Project files. Every team member can see the latest version of the schedule without any conversions or PDF printing.

Tools in project

2007-05-19T00:15:00.000+02:00

It is astonishing how much we can gain by using right tools in our projects. Generally it is obvious that better tools provide better performance and help to achieve better results. If so, ask yourself how often you calculate profitability of purchasing new tools. I suppose not so often, though we know that the total cost of development, engineers performance and the future of the organization, may sometimes depend on a single purchase / development decision.

Let’s analyze an example:

We are to realize a project based on standard components with only one new element. The new element must be developed and integrated with our regular environment. To make it easier let’s assume that the element is described by some standards and we are not able to negotiate this issue with the customer! It is a must issue and will be certified in detail.

Usually we:

Organize schedule in such a way as to detect possible problems related with the new element as soon as possible.
Allow additional time to learn the new technology and deal with potential problems
Manage the risk related to the development of this new element

During the project execution we usually face problems which cost us some extra work, but thanks to our plan we are able to finalize our projects within the scheduled time and budget. Then we can sit back in the armchair, and think “Success!”.

But the real success depends on the way we have selected.

Example1: Minimum additional expenditures

“The budget is not made of rubber; it will not stretch to cover everything”. - We didn’t have enough resources to buy or create any additional tools.

Our project schedule has necessary buffers for surprises because we are not able to negotiate the deadline.
Some of our people probably had to work overtime to meet the deadline.
Our QA spent significant part of their time testing the new element and its surrounding.
Next project using this new element may still require some more testing around this area.

But well, new elements always cost more anyway.

Example2: Budget assigned for tools

We are able to purchase some tools or delegate an engineer to develop the necessary tools.
Our people have more comfortable development environment and can identify most of the problems related with the new element very early into the project.
Our QA can start from very sophisticated test-cases because the new element is already almost operational.
Our engineers are able to quickly reproduce and analyze the issue reported by customer
Our people do not need to work overtime to fix all bugs related with the new element.
The new element easily becomes one of our strengths distinguishing us from other competitors
Our tools can be improved or combined with other ones and create new value for our company.

Everything depends on the concrete situation, budget, time and resources; however it is good to be aware how the tools may be essential for current and future projects. Reasonable investment in new tools may increase our competitiveness on the market, reduce cost and improve motivation of employees.

dotProject

2007-05-02T23:19:00.002+02:00

dotProject is a free and open source tool for managing projects. If you would like to see the system in operation - use the Demo Link
Username: admin/Password: admin
Username: guest/Password: guest

Manager or Leader

2007-05-02T20:43:00.000+02:00

Are you a Manager or Leader?

Think a bit about it.

Manager
•Build systems and procedures
•Find comfort in the status quo
•Settle for industry standard
•Wield power
•Control, Instruct
•Formulate policy
•Reactive
•Plan

Leader
•Build teams and develop talent
•Serve as a catalyst for change & growth
•Demand the best
•Apply influence
•Inspire, Mentor
•Set examples
•Proactive
•Innovate

Evaluation and Modeling Tips

2007-04-21T23:31:00.000+02:00

New discovery - List of occasional "Tips" Short descriptions of books, articles, techniques and ideas for better business and personal decisions. I like to learn new points of view on some interesting topics. Descriptions are not so deep, but allow to grasp the main author’s idea.

Personality Tests - fun and self improvement

2007-04-10T20:32:00.000+02:00

Personality Tests is my latest discovery. It is a site with many psychology tests gathered all in one place. All test have description and specified solving time. While solving them I had great fun and chace to think again about myself because some results were really puzzling.

PM Internet tools - Basecamp & Highrise

2007-03-26T14:13:00.000+02:00

Basecamp can help you to improve communication with your customer. It has some limitations but can be very useful.
Highrise can help you to improve communication in large scale multisite environments or simply communication inside your team.

Links to sites about managing

2007-03-17T23:28:00.000+01:00

allPM forum
Something for the cold winter's evening
IT toolbox - Project Management Knowledge Base
Rumble forum,groups,lot of data

MS Project links

2007-03-08T20:09:00.000+01:00

One common place for the MS Project links. This post will be updated every time I find something interesting.
MS Project templates
Create the template of the project according to the organization rules with your typical deliverables.
MS Project tips
A few basic tips – very useful
Set of articles about all aspects of MS Project
These articles allow you to understand many aspects of MS Project
MS Project faq
MS Project faq and additions
Merlin 2.0
MS Project on a mac? Under Parallels or.... just Merlin.
OmniPlan
Another MS Project on a mac.