The Project Management Blog

Rule #6: A comfortable project manager is one waiting .....

projman — Thu, 02 Jun 2005 16:58:00 GMT

Rule #6: A comfortable project manager is one waiting for his next assignment or one on the verge of failure. Security is not normal to project management.

Rule #5: Vicious, despicable, or thoroughly disliked persons...

projman — Thu, 02 Jun 2005 16:57:00 GMT

Rule #5: Vicious, despicable, or thoroughly disliked persons, gentlemen, and ladies can be project managers. Lost souls, procrastinators, and wishy-washies cannot.

Rule #3: Management principles still are the same.....

projman — Thu, 02 Jun 2005 16:56:00 GMT

Rule #3: Management principles still are the same. It is just that the tools have changed. You still find the right people to do the work and get out of the way so they can do it.

Rule #4: Whoever you deal with, deal fairly.....

projman — Thu, 02 Jun 2005 16:56:00 GMT

Rule #4: Whoever you deal with, deal fairly. Space is not a big playing field. You may be surprised how often you have to work with the same people. Better they respect you than carry a grudge.

Microsoft Visual Studio 2005: Team System

projman — Fri, 27 May 2005 07:41:00 GMT

Thanks Guys!!

What an awesome solution! This is what every analyst, tester,QA, project manager and developer is waiting for.

Microsoft Visual Studio 2005 Team System will cater for the full life cycle. A golden thread is drawn from analysis to final delivery. Easy access to accurate information about your project empowers developers to deliver more effectively. It also allows PM's to manage much more pro-actively and effectively.

Microsoft Team System allows users to drill into project information I a variety of ways but I believe pivot tables will add the most value for PM's. PM's will have access to more information than ever before.

This tool is designed for Microsoft MSF Agile, but can add value to ANY project. This is a MUST HAVE for me.

Beta and information available at: http://lab.msdn.microsoft.com/teamsystem/

I will post some more information around the value and benefits of Team System and MSF.

Willem Viljoen

Statistics... :-)

projman — Fri, 27 May 2005 05:21:00 GMT

1) 10 % of all car thieves are left-handed. All Polar bears are left handed. If your car is stolen, and you live in the northern hemisphere, there is a 10 % chance that it was stolen by a Polar bear.
2) 39 % of unemployed men wear spectacles. 80 % of employed men wear spectacles. Work stuffs up your eyesight.
3) All dogs are animals. All cats are animals. Therefore, all dogs are cats.
4) A total of 4000 cans are opened around the world every second. 10 babies are conceived around the world every second. Each time you open a can, you stand a 1 in 400 chance of becoming pregnant.

This is why I believe 97.1234567 % of all statistics are made up by people with nothing better to do

Rule #2: A project manager must know what motivates .......

projman — Fri, 27 May 2005 05:07:00 GMT

Rule #2: A project manager must know what motivates the project contractors (i.e., their award system, their fiscal system, their policies, and their company culture).

Rule #1: A project manager should visit everyone.......

projman — Thu, 26 May 2005 11:48:00 GMT

Rule #1: A project manager should visit everyone who is building anything for his project at least once, should know all the managers on his project (both government and contractor), and know the integration team members. People like to know that the project manager is interested in their work and the best proof is for the manager to visit them and see first hand what they are doing.

100 Rules for Project Managers (Daily)

projman — Thu, 26 May 2005 11:47:00 GMT

I have found a list of 100 rules for NASA PM's (writen by Jerry Madden). These gems are still valid today and will assist PM's regardless of industry and skill level.

A new rule will be posted every day. Sign in regularly for an update!!

Willem Viljoen

So You Want To Be A Project Manager? (Interesting Article)

projman — Thu, 26 May 2005 11:38:00 GMT

So You Want To Be A Project Manager?

by Mike Harding Roberts

Only ex-programmers really know how to manage software projects. Nobody else really understands why it's so important to pin down the requirements, get the design right, get the development environment established and so on before coding begins. This is not to say that all programmers and analysts are paragons of project management virtue - if only it were so!

Everyone loves time recording, don't they? How many hours you spent doing task A or task B or chatting about the football or blowing your nose. And for what? To give some guy in the project office a job collating the numbers, which we all know are a fiction anyway.

And what about all those forms and documents, all that bureaucracy which seems to have a life of its own? Well, it seems to keep the project manager happy and to satisfy the methodology police. But just think how much quicker we could do the project if we were left to get on with it without all those project management overheads!

And what does the project manager do all day anyway? Of course they have to do all the obvious things like get resources, define roles, plan, track, report and so forth, but maybe there are some less obvious things they should do as well. Make the project fun. A happy workforce is a productive workforce. Hold kick off meetings, arrange social and team building events, reward success - a pat on the head or even a small amount of the folding stuff. Walk about and keep in informal contact with the team. Good project managers don't only know how to operate the hard-edged project management disciplines, they are good people managers too.

And good project managers have other characteristics. They manage. They don't co-ordinate, preside, administer, spectate - they manage. They don't like surprises so they work very hard to prevent them: they plan in detail, try to foresee problems and eliminate them before they occur. They monitor rigorously so they know as soon as things are going off track. But when problems do occur they deal with them, they address conflicts, fight fires. Yes, they reward but they also punish. They make decisions, arbitrary ones when necessary. They get consensus when they can but dictate when they have to.

They scale the project management controls to match the real needs of the project so that they don't smother smaller projects with unnecessary bureaucracy. Then they explain to the team what the controls are for, why they are an investment not an overhead, how time records will be beneficially used and therefore why accurate time recording is worthwhile.

And you still want to be a project manager?

How do you learn to be a project manager? Go on a project management course obviously. But beware, there are many sorts of "project management" courses. Some teach you how to use a planning tool like Microsoft Project. A useful skill but you've learned how to use a tool not how to manage projects. Some teach the administrative strictures of a particular project management method but they may not actually teach you all that much about how to manage projects. Some project management courses offer a qualification, but the primary aim of these courses is to get you to pass the exam at the end of the course and again they may teach you little about managing projects. And then there are courses which do teach you how to manage projects. When choosing a course be clear what your objectives are and choose appropriately.

So, you've done a course, now what? You might think that managing a small project would be the next logical step. However, you will probably gain more valuable experience by being a team leader in a large project. When running a small project the budding project manager learns an unfortunate lesson: you don't need to bother with all that formal project management stuff - and they're right, you can be perfectly successful in small projects with little formal planning and control. But you then give that project manager a large project to manage. They know that an informal approach works, they apply it to the large project, and you have a disaster in the making.

By contrast, if you're leading an 8 person team in a 100 person project all the controls that big projects need will be in place (one hopes!) all around you. You will get to see exactly how it all works without having the responsibility of managing the project. This is excellent experience for would-be project managers. If your next job then happens to be managing a small project it's easy to scale down the controls. But it does not work the other way around - informality does not scale up.

"Excellent course but I've realised one thing - I definitely don't want to be a project manager!" This is occasionally the reaction from people at the end of a project management course and their rationale is usually: why would anybody want a job where success means everyone assumes it must have been easy, and problems mean you're going to get kicked. Equally (fortunately) some people have the opposite reaction: "yes, this is the job for me!" And these people are attracted by the idea that they can make things happen, make a difference and manage projects better than other people.

http://www.hraconsulting.fsnet.co.uk/project-management-training-course-uk.htm

The Tale of Three Project Managers

projman — Wed, 25 May 2005 16:44:00 GMT

The Tale of Three Project Managers
a project management cautionary tale by Mike Harding Roberts

The project

A two week journey in an open boat down a raging jungle river.

Let us see how three different project managers approach this project.

1. Ivor Fairway-Handicap's tale

Ivor: "Cast off!"

An hour later the river is fast flowing but deep and smooth. "This isn't so bad! Look, we're past the first milestone! Well done crew!"

A little later they come upon the first rapids. A worried crew member asks: "Er, what about lifejackets?" Ivor replies: "O.K. Meeting this afternoon to consider. All proposals welcome." The meeting is duly held though the rough ride makes it difficult. The need for lifejackets is agreed. A subcommittee is established to consider what type of lifejacket might be best.

Later, another crew member asks whether oars would help in the increasingly turbulent waters. A meeting is scheduled.

After another few hours of being tossed around in the now violent waters a crew member says someone should be steering. After mildly rebuking the crew member for seeking to make such an arbitrary decision Ivor sets a time for a meeting to discuss whether the boat should be steered, if so by whom and how directional decisions would be arrived at consensually.

Unfortunately, before the meeting can be held the boat is hurled onto the rocks and smashed to matchwood. Half the crew drown in the rapids. Ivor and the survivors hike for 3 months through dense jungle. At the coast they are spotted and helicoptered to safety. The team praise Ivor's warmth and humanity. He becomes a hero and is knighted for his bravery in taking on what, with hindsight, was such a dangerous venture and for leading the survivors to safety.

2. Colonel Bee-Bee's tale

"Wow, just a minute - is this wooden boat a good idea?" The Colonel decides to take the white-water inflatable instead. Life jackets, paddles and supplies are loaded. They cast off for their two week trip.

At the violent rapids they capsize. The crew all make it to the bank. There is one broken arm. After a day's rest they set off again.

Later two crew members are swept overboard, but are rescued by the crew. After 8 days they discover a waterfall - the hard way. There are no fatalities but it takes 4 days to effect ingenious repairs to the inflatable using jungle gums, leaves and creepers.

The food runs out, but two days hunting and gathering replenishes stocks.

Finally, after a month's travails they arrive. Colonel Bee-Bee is sorry they are two weeks late. But all conclude this was entirely due to circumstances beyond his control. He is promoted to Brigadier.

3. Jim McB'stard's tale

"******* ****! This is ******* stupid." Jim disappears for half a day, leaving instructions for his crew to get themselves sorted out, work out how they'll handle any rapids etc. Jim reappears with an unwilling native in tow.

They all board the inflatable. As they cast off the river level suddenly drops dramatically and the river flow slows. "I told the **** up at the hydroelectric dam to close the sluices," Jim says.

The inflatable proceeds quickly but not suicidally. The rapids are rapid but not murderous. There are cuts and bruises from the violent buffeting, but no capsize and no men overboard.

On day 6 the native gets excited and gesticulates wildly. A waterfall, somewhere ahead, seems to be the message. They land and spend 3 days hiking around the waterfall.

There are some very close moments on the trip, but after 3 weeks they arrive.

Jim is thanked for bringing the crew back safely, if a little battered. Jim is criticised for being a week late. The experts point out that if he hadn't wasted 3 days walking, and if he hadn't had the river flow slowed they would have made it in 2 weeks easily. Jim is promised another trip to organise so he can do better next time.

http://www.hraconsulting-ltd.co.uk/project-management-tale.htm

Why do projects slip and developers burn?

projman — Wed, 25 May 2005 16:25:00 GMT

I know this is a question asked by many.

If you had to provide reasons why you think projects slipped and the developers had to work like deamons to try and make the deadlines (OF COURSE HIS NEVER HAPPENS) the top answers will be:

1. Developers did not have input on the timeframes and planning of the solution.

2. Scope wasn't managed effectively and new features were added and the timeframes were not extended.

3. Scope was never fixed or agreed before development started.

4. The analysis was not done well and there were “gaps” in the documents and requirements which meant that the developers had to go and do some analysis, redesign and redevelopment.

We have all discussed the above in a variety of forums, but I would like to add another view.

Why do we always identify the slippages at the end of the milestone/project? Why do we always burn at the end?

Could it be that we do not have a effective communication channel where the developmnet team can raise their concerns, or report slippages the moment they occur? Ultimately if the PM is aware of the slippages/concerns of the team the moment they happen (a day or week after it started) he/she will be able to immediately start assisting the team. Puting alternative plans into place and alleviating the pressure....

Have any of you experienced this before?

Communication is important

projman — Wed, 25 May 2005 16:12:00 GMT

Communication is key for delivery if any project.

Communication takes many forms. Written, emotional, verbal, visual, audio etc. It forms the foundation for gathering requirements, sets the tone for customer involvement, assists in resolving issues, allow the teams to work more effectively, addresses user concerns and many more.

Effective communication is further not about what is said, but HOW it was conveyed.

I almost feel that every team should have a bit of communication training before every project.

Below some interesting communication reading:

http://www.agilemodeling.com/essays/communication.htm

http://www.ncrel.org/engauge/skills/effcomm.htm

Willem Viljoen

Do Project Managers add value?

projman — Tue, 24 May 2005 09:02:00 GMT

I am interested in hearing your opinion about the following:

Do PM's add value or are they just a waste? (please substantiate your answer)
Is Project Management a specialised skill or can anybody be a PM?

Willem Viljoen

Workshops - crucial part of any project

projman — Tue, 24 May 2005 07:31:00 GMT

We all agree that workshops are crucial to gather information, resolve issues etc.

How effective are we at running workshops and do we have the correct people present in order to benefit the most?

The following document describes the process, people that should be attending and what the structure should be.

I firmly believe that this is not the only way in which workshops can be conducted, but we can learn from each other and in the process become better.

It's a win-win scenario.

http://www.ebgconsulting.com/IEEE%20rqts%20column%203-03.pdf

Willem Viljoen

The Project Management Blog

Rule #6: A comfortable project manager is one waiting .....

Rule #5: Vicious, despicable, or thoroughly disliked persons...

Rule #3: Management principles still are the same.....

Rule #4: Whoever you deal with, deal fairly.....

Microsoft Visual Studio 2005: Team System

Statistics... :-)

Rule #2: A project manager must know what motivates .......

Rule #1: A project manager should visit everyone.......

100 Rules for Project Managers (Daily)

So You Want To Be A Project Manager? (Interesting Article)

So You Want To Be A Project Manager?

The Tale of Three Project Managers

The Tale of Three Project Managersa project management cautionary tale by Mike Harding Roberts

The project

1. Ivor Fairway-Handicap's tale

2. Colonel Bee-Bee's tale

3. Jim McB'stard's tale

Why do projects slip and developers burn?

Communication is important

Do Project Managers add value?

Workshops - crucial part of any project

The Tale of Three Project Managers
a project management cautionary tale by Mike Harding Roberts