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

Friday, 28 August 2015

The Product Based Planning technique is a great way to start your Planning

You are given a Project to plan, where do you start? Product based Planning is a powerful technique and a good starting point for your Planning activities. It produces a roadmap for the Project and ultimately identifies a good proportion of the tasks for your schedule. So if you don't know the technique, read on for how I tackle with a worked example using my favourite Project of making a Mug of Tea.
Product Based Planning - Mug of Tea

Work out final and intermediate Products - a Product Breakdown Structure (PBS) may be useful

The first step is to work out what Products are to be produced / utilised by the Project. The final one(s) should be easier to define but then you need to think of intermediate ones - those which are needed to achieve the final Products.

A Product Breakdown Structure (PBS) may be useful to tool to help in the thinking process and ensure that you have identified all Products.

It shows the breakdown of the final Product with intermediate Products and a breakdown of these if appropriate but doesn't imply any order of production. Some tips are:
  • the top of the structure is the Final Product
  • show Products NOT Activities (look for nouns or outcomes in the past tense). So don't confuse with a Work Breakdown Structure (WBS) which is concerned with activities. For example, "trained workforce" is a valid Product, "training workforce" is not. This may seem semantic but it is quite important
  • distinguish "External" Products which exist already (e.g. brought in, provided by another Project) versus "Internal" Products which need to be created by the Project
  • Products under another Product go to make the higher Product
Mug of Tea Project - Product Breakdown Structure
Mug of Tea Product Breakdown Structure (PBS)
The key to the above PBS is:
  • Rectangle - Product produced by Project
  • Eclipse - Product external to Project. So these become External Dependencies
  • Rhomboid - not a Product but a collection of Products
So here is my list for a "Cup of Tea" (actually Mug because a cup isn't big enough)
  • Mug of Tea - the final Product
  • Consumables - Teabag, Cold Water, Milk (all Dependencies as I am assuming someone else has provided these) and Hot Water which is a Product produced by the Project
  • Equipment - Mug, Spoon, Kettle (all Dependencies as I am assuming someone else has provided these)
In theory you should produce Product Descriptions (PD) for all these Products, but often I believe the information can be held elsewhere in your Plan as per my post on Product Descriptions

A Product Flow Diagram (PFD) is useful if the order of Use / Production isn't obvious

The Product Flow Diagram (PFD) shows the sequence of use / production of the various Products identified by the PBS. Here is the Mug of Tea example


Mug of Tea Project - Product Flow Diagram
Mug of Tea Product Flow Diagram (PFD)

This Product Based Planning now assists in production of your Plan Schedule

Firstly, the product list and sequence is a useful way of assessing Project progress outside the schedule by answering two key questions:
  • has the Product been produced?
  • has the Produce successfully passed the Quality process defined for it?
I have even used this basic approach as a simplified approach to measuring Earned Value, a topic I wrote a presentation about a few years ago.

Secondly, this gives you the framework to produce 80% of your Plan Schedule:
  • task(s) and resource(s) to produce the Product. Estimate effort to produce and thus duration
  • task(s) and resource(s) to quality assure the Product. Estimate duration (and effort) to undertake the quality plan (see post on document quality planning but other Products need quality plans too)
  • Some task dependencies implied by the PFD, others obvious (you can't quality assure a Product until it is produced!)
  • Don't forget Management Products (to operate the Project) if your Product based Planning has focused on Technical Products
So here are 80% of your tasks and a framework to fit the remaining 20% of tasks such as Risk management actions, Communications etc. With a bit of resource levelling thrown in, you have your Schedule - a great job all based on Product Based Planning!!

For the Mug / Cup of Tea example, you can take a look at my posts on scheduling
You may also want to look at my post introducing Planning

Wednesday, 12 August 2015

Behavioural Traits of a good Project Manager

A Project Manager needs a number of different skill-sets which I have covered in this Blog. Firstly are what I call technical skills; these cover the basic techniques used such Planning, Estimating. Monitoring & Control etc. Secondly, as Projects are about bringing together a team to achieve an objective, People Management skills are important or the human side as I prefer to call it. You could add some general skills such as Communication into the skill mix required. However, I believe that good Project Managers need more than these skills to achieve in the most challenging Projects - they need the right behavioural characteristics. These are more difficult to acquire as they will be linked to your personality type (see Human side post) but I believe everyone can adapt to some degree to develop these traits.

1. Doesn't duck difficult issues and is prepared to stand his/her ground

It is likely that at some point in your Project you will have a difficult issue to resolve or someone may try and impose something which threatens the outcome you are aiming for. Don't hide away from the difficult issues and be prepared to stand your ground as necessary. At some point you may need to involve your Sponsor / Project Board to assist you as they ultimately own the Project.
Project Manager - If you don't stand for something you'll fall for anything

2. Is self motivated and resilient to setbacks

Typically nobody is going to motivate you as Project Manager so you need to be energised by the tasks at hand and never lose sight of the ultimate goal. Team members will be looking at you so try and display energy and commitment - even when you don't quite feel like it ;-)

You are likely to have a few setbacks and you need to react correctly and continue to strive towards the end goal. In a previous post I drew parallels between a Project Manager and a Military General so remember you may have a setback in a battle but still win the war!

3. Prioritises effectively

Despite good planning and estimating practices there will be occasions when things need to be prioritised whether personally or within the team. You need to be able to sort the important things from the rest, be decisive and make the priority calls. My top tip is to ask the question against each task, how much risk does delaying this task add to achieving the Project objective? Pick the highest risk item!

4. Has networking skills to obtain information and support

You will often need information and support from outside your Project team. You should be a good networker and be able to act both formally and sometimes behind the scenes to gather information and get things done. Encourage your team to do likewise. 

On one IT project my architect had established an extremely good network of informal contacts within the organisation. When we had environmental issues which we didn't have the skills / privileges to diagnose and resolve within the core team we adopted a twin track approach. I would try and get support through my network at the management level and he would call in some favours from his network more at the "coal face". We used to have a side bet which approach would get resolution quickest - he often won!

5. Is Effective under pressure

You are likely to come under pressure at some points in your Project. To be a good Project Manager you need to maintain clear thinking in these pressure points and certainly not panic.  

6. Has Honesty in communications

Tell most internal stakeholders (especially the Sponsor) how it is and when necessary say "I don't know". If you have to say "I don't know", be prepared to explain what you need to do before you can give an answer, don't just make it up as per the cartoon below! A "good news" Project Manager (one who doesn't want to give bad news) is ultimately not going to get the job done. Some external stakeholders may need special treatment from a good spin doctor - see my post on Stakeholder Management.
The most valuable and least used phrase in a Project Manager's vocabulary is I don't know
In 95% of cases I will also be very honest with my Project team as my instinct is to call it as I see it whether on individual performance or status. In 5% of cases I will be less honest but for (what I feel) are the right reasons e.g. to protect a team member or avoid the person being totally demotivated. 

To Summarise...

To be a good Project Manager you need a number of behavioural characteristics. Many will speak of being a leader not a manager but I have tried to be as specific as possible in the traits I look for when assessing Project Manager performance. But certainly someone who has personal presence and impact will likely be a better Project Manager as long as they have the technical, general and people management skills too.

Twitter Delicious Facebook Digg Stumbleupon Favorites More