First time visitors read!

If you are new to this Blog, read about it's purpose and how to get the best from it

Free Project Management Training

Go through the site content in a structured manner to teach you Project Management or improve your success rate

No English?

Can't speak English? No problem!!

Why the Sheepdog Analogy?

A Project Manager is a necessary evil. Why? Well, the PM doesn't produce anything - write code, lay concrete or whatever. However, don't have one and see what happens!

Always telegraph your Punches as a Project Manager

Sometimes as a Project Manager you need to throw a "Project Manager punch" but not a literal one please!

Isaac Newton's contribution to Project Management

Newton's laws, especially his first law of motion, should be as important to a Project Manager as it is to a Physicist. Why?

O Sponsor, Sponsor! wherefore art thou Sponsor?

You are given a project to run. Amongst your early questions should be, "who is the Sponsor?"

Always remember the Human side

It is very easy to get hung up in the technical and management side of Projects and forget that they need to be delivered by human teams. So "Always remember the human side" is the key phrase!

Why writing a Project Status Report is not a chore

I've met several Project Managers who view writing any Project status report as a chore. I think the opposite.

Planning is the key Project Management discipline

I have been asked a few times, "What are the top xx things to focus in on as a Project Manager? If pressed, I always fall back to Planning

Saturday, 27 December 2014

Happy New Year to all Project Teams

As we near the New Year, it is a time for reflection with your Project Team on what has happened in the year, both positive and negative, with an emphasis on what has been achieved. Then we should focus on what needs to happen to ensure a successful Project completion in the next year. What better a way to do this than with a song - have you ever heard a Sheepdog sing?
Happy New Year

No more issues
No longer in a mess
Here we are, no more stress
We are making good progress
It's the end, of the year
No more mornings where we pray
So unlike, yesterday
Now it's time for us to say...

Happy new year
Happy new year
May we all, have a vision of our team
Of a project, that has reached our greatest dreams
Happy new year
Happy new year
May we all, have our hopes, our will to try
If we don't, we might as well lay down and die
You and I

Sometimes I know
Project status must I RAG
Oh I like, the green flag
But no time to stop and brag
Risks remain, we must check
As we push, for the finish line
Spirits strong, a good sign
Soon to open party wine

Happy new year
Happy new year
May we all, have a vision of our team
Of a project, that has reached our greatest dreams
Happy new year
Happy new year
May we all, have our hopes, our will to try
If we don't, we might as well lay down and die
You and I

A note to ABBA - Thank you for the music, the songs I'm singing, thanks for all the joy they're bringing

Friday, 19 December 2014

Work Package principles can be applied in a number of Project situations

My belief is that the principles of Work Packages can be applied more often than you may initially think in Projects; it is just the formality of definition that may differ in various circumstances. So, sub-contracting a part of the plan to a third party is an obvious use of a quite formal Work Package, but can a request for a team member to undertake a task on the plan be considered a Work Package or even a Meeting?

The most formal Work Package definition

Project Work Package in Action

The most formal Work Package definition could have the following elements:
  • any background information and context
  • description of what is to be delivered - product descriptions in PRINCE2 terms
  • agreement on effort / cost, time for delivery and when to start
  • quality criteria and checking approach which may require independent attendance at some review sessions
  • any other constraints
  • standards, techniques and processes / procedures to use
  • interfaces to be satisfied
  • requirements to be met
  • progress reporting requirements
  • problem processes
Ultimately this Work Package could be linked to a contract with a third party but a similar approach might be adopted for some major deliverables produced by a team reporting to the Project Manager.

Asking one of the team to deliver something in the plan?

When you want someone in the team to deliver a task in the plan many Project Managers will take the informal approach with a a quick chat. I too like the human element of this approach, you can have a discussion, understand risks etc, look the person in the eye and gain a commitment. 

But one of my sayings goes What isn't written hasn't been said. If you actually covered all the aspects of the formal work package in your verbal discussion that would be good but you may miss a point or two and the memory of some team mates can dissipate when under pressure or something more interesting pops up ;-)

So I suggest you reinforce the discussion with a quick email summary, you can provide links to reference material within the Project File which ensures there are no excuses and can actually help the team mate as a reference point as the work progresses. 

You can mention things like progress reporting too, "can you pop me a quick email each Friday morning with progress made, effort to complete, any issues or risks you wish to raise?" In some circumstances, especially when a task is on the critical path, I may set up a zero length meeting request for the person on the Friday morning. This reminds the team mate and reminds me too about expecting an email status update. So if the email doesn't arrive on the Friday by lunchtime, I can chase Friday afternoon.

Applying Work Package principles to a Meeting?

OK, it may be stretching things a little but some of the Work Package principles I apply to meetings:
  • In the Outlook meeting invite I often put some background information and the objective / questions to answer. As well as hopefully allowing participants to think about their contribution BEFORE the meeting, this is useful for me when I am going from meeting to meeting during the day as it helps me get my brain in gear rapidly!
  • I also like to start each meeting with what I call the "warm up" - the analogy here is the audience warm-ups before TV recordings or similar. It ensures that the "audience" is in the right frame of mind for the meeting, understands the context and to set expectations on what is to be achieved - maybe as per the cartoon below :-)
Project Meeting Warm-Up

Monday, 8 December 2014

Do better than the Ancient Egyptians - Have a well organised Project File

Historians have deduced that the Ancient Egyptians must have had very poor filing systems - this is why they chose to write all their history on the walls :-). You need to be careful not to repeat this situation in your Project else the team will have difficulty finding useful documents / information resulting in communication problems, a loss of productivity and a lack of auditability.
Have a well organised Project File
Here is my suggested check-list for establishing and using a Project File

1) Shared File Store

First and foremost you need a Shared File Store which all the Project team can access. The old fashioned way of achieving this was a Project folder on a Shared drive. This can still work although many organisations have SharePoint and you can establish a Project specific site. SharePoint has a number of useful features which you don't get with a Shared drive such as Document Check-Out / Check-In, the ability to make a more interesting site through web-parts etc. 

Please check that this shared file store is backed up, ideally nightly.

2) Create a Project File Structure to aid easy retrieval of Information

Don't assume that your team will organise things sensibly, they won't! So dictate a sensible structure. Give this some thought, it will pay dividends in the long term. So for example, in IT Projects adopting a waterfall SDLC type life-cycle you might have a Management folder plus one for each major phase. Then I would encourage use of sub-folders below this basic structure.

3) Communicate structure and dictate usage to the team

Make a summary document about the structure and communicate this to the team. If it is a SharePoint site, this introduction to the structure can be made prominent for "new users" of the site. 

Tell the team that they need to use the Project file when drafting new information not just when submitting for review (every heard the story about the person who lost a months work on a draft document stored on the "C:" drive when it failed?).

4) Use link to Project File in Emails

Ensure the team utilise links to documents within the Project File rather than embedding them in emails which wastes space on the organisation's email servers with duplicated copies.

5) Consider document version control practices

In general terms I adopt the following principles on document versions.
  • Drafts should progress through versions 0.1, 0.2, 0.3 etc 
  • When the document is baselined (see previous post on document quality) it moves to the next integer, typically 1.0 for first baseline, 2.0 for second baseline. Ideally I like the evidence of signoffs to be embedded in the baseline document
Some practices will change depending on the technology used for the Project File:
  • Shared Drive - To support configuration management, I like the version number included in the file-name
  • SharePoint - This should be set-up to maintain versions and the version number should always be excluded from the file-name. I have yet to crack using the SharePoint version within the document (let me know if you know how!) so for me the version number embedded in the document change history section is the Master version label

Lastly - Stamp on "poor team behaviour"

You have communicated about the structure of the Project File and how it should be used as above. But you need to acknowledge that your team are humans and humans are set in their ways. Remember my post on Newton's 1st law of motion (People tend to continue travelling in the same direction.....unless acted on by an external force)

So be prepared to call out poor team behaviour (e.g. emailing documents around) and by catching this early you will get the team all pulling in one direction in the use of a well structured Project File which will be a useful asset in your Project execution.

Twitter Delicious Facebook Digg Stumbleupon Favorites More