Download Your Free Kick Start Guide

Tired of Just Surviving Your Projects ? Seize Control From The Outset... Learn How With This Simple FREE Guide

Got You Covered – 5
Got You Covered – 1
Got You Covered – 4
Got You Covered – 2
Great PM Techniques Team Issues

Your Next Team – Confusion, Poor Behaviour, Broken Promises, or Sheer Genius?

Does this sound familiar?

A project team that is just surviving or perhaps even dying – operating in constant chaos or at best just staying afloat. Plagued by too many issues:

  • Too many missed targets
  • People at each other
  • Unacceptable behaviour
  • Project owner unhappy
  • Low-quality delivery
  • High attrition rates
  • Too many distractions

I’m sure what we all thought when we started our project we would have a fully focused, happy, distraction-free project team working together to crush project milestones, have the ability to manoeuvre quickly to deliver innovation with breakthrough quality, and end up proud of what they have achieved.

You don’t have to be some type of mystical or charismatic leader to make this happen.

You simply need to establish the right environment for the team to work, keenly observe the team function, and with a few tools in your back pocket, recognise and root out issues.

Like with most things you need to develop, it takes just two ingredients to cook up a solution:

  • Knowing what is actually happening
  • Knowing what to do about it

Of course, some super powers would help – and your super power to develop are these 2 things in the context of your team, in your situation. The second one helps inform the first. The first informs the second.

Naturally, no team is ever one thing – total chaos or total genius. They are usually moving somewhere along a continuum between the two.



What we need to do is develop the skills to know how to gently and subtly guide that position towards the right – towards genius.

9 Steps Towards a Genius Team

So, here are some steps that may help you on the way:

Read More
Great PM Techniques Team Issues

Productivity Part 2 – A Formula – But Why?

Ok – so last week I wrote about a funny looking formula – a productivity formula.

But why should you care? How’s it going to help you?

I know summing up human-related project matters as a formula might make you think:

  1. Load of useless pseudoscience to make Mark think he looks smart – bleh
  2. The real world doesn’t work to any formula – bleh
  3. Who cares – I’ve got a team that every day seems to not get things done – HELP ME WITH THAT PROBLEM, PLEASE?

Maybe there’s truth in all of those statements (depending on your viewpoint) and you are right – a formula is NOT necessary … but there is a useful aspect. Let me explain.

You see, having a formula or a structured way of thinking helps you assess the aspects that could actually be constraining the productivity of your team.

So here’s the formula again:

Actual Productivity = ((((quantity of output / unit of effort) * time) * level of quality) * maneuverability factor) – (distraction factor + process overhead factor)

(You know – looking at it again it does look pretty OTT… (Over The Top – for those who don’t know that old three letter acronym). Now – I also refined my brackets from last week (I spotted an annoying flaw – I was reducing the amount delivered over time by not adding an appropriate bracket before time, instead of increasing it. I have updated that previous post.)

So let’s look into it.

Read More
Great PM Techniques Planning Team Issues Tracking

How to measure project team productivity – Is There a “Magic” Formula?


It’s an issue that plagues every project manager – productivity.

How do I get my team to work better/smarter/more effectively?

I was pondering this question recently and while we are all aware that there has been plenty of theories, formal studies and processes available, I wondered if there was something that can sum it up for me – something like a formula that I can apply.  ( I don’t know about you but I like things to boil down to just a few simple steps that I can easily follow or absorb to carry around in my back pocket).

As it turns out, there is – I mean there is, beyond the normal “how many widgets did we deliver against our baseline/target”.

Agile software’s approach to measuring productivity – velocity

Agile software development has a some really nice ways of creating a predictable gauge of progress. By time boxing each sprint we can work out how much a team can get done in that time. The best way to do that is not by how many “stories” or “features” can they produce in that time, but instead, they use a points system.

By time boxing each sprint we can work out how much a team can get done in that time. The best way to do that is not by how many “stories” or “features” can they produce in that time, but instead, they use a points system.

The best way to do that is not by how many “stories” or “features” can they produce in that time, but instead, they use a points system.

They allocate points to each story or part of a feature they want to achieve. Once achieved they can claim those points as the measure of achievement within each time box.  This then becomes the team’s “velocity“. That is, how many points can be achieved in each sprint’s time-box.  You keep one variable constant – time. Brilliant.

The main issue in determining productivity is in measuring the size of the things you want to deliver.  The allocation of points is a great way of doing that even if it can be a bit arbitrary. Agile get over this arbitrariness by using the whole team to estimate the points. At least then they aren’t getting just one person’s viewpoint. And there is a sense of being part of the estimate by ALL members of the team – it’s like “we set the scale, so we can’t complain”.

Agile get over this arbitrariness by using the whole team collectively to estimate the points. At least then they aren’t getting just one person’s viewpoint. And there is a sense of being part of the estimate by ALL members of the team – it’s like “we set the scale, so we can’t complain”.

Of course, as the project progresses and the more sprints completed, the more accurate the velocity becomes.

The main thing is that agile projects don’t necessarily use this measure as a measure of productivity – but more as a baseline prediction tool to measure what can be achieved over time – say to the next release of their software deliverable.

The quality dimension

The other point is that if we start fixating about velocity, we can forget one very important aspect of delivery – quality.

There is little point in our team being proud

It is an important human, team and project trait. We tend to get fixated on what we measure.

If we are to be judged by say our velocity, we may let other measures drop.

This is a classic assembly line problem. Measure how many widgets are coming off the assembly line, then we forget that each widget might end up being rubbish. All because we are being measured by velocity.

We need quality.

Most team leaders realise this – and it is an important aspect of every project and every team.  No point pumping out junk – you can, but the team won’t last long! Customers won’t want to buy what you are producing, or at the very least, your product owner will not be happy.

Equally, letting the quality dimension only drive the equation, you may very well achieve nothing (Oh that sounds like perfectionism!)

So, what is productivity?

That’s great – but what about other projects / other teams? No two teams are the same, no two circumstances are identical. We are not all agile project teams, in fact, a lot of teams produce something and are not a project – like client-support teams, or call center teams – they produce help or sales and not “things” as such.

Generically speaking then, productivity can be measured by the volume of quality things being produced per unit of effort in a set amount of time.

The issue we need to consider is the negative impact of inefficiencies.

As we all realise, if we have to be constantly stopping to check where we are at we slow down. So process efficiency is a big consideration in determining our team’s productivity.

So we need to keep process to a minimum, otherwise, we negatively impact productivity. Be constantly looking out for ways to improve efficiency especially as teams grow and layers of bureaucracy creep in.

A general formula

So is there a formula or some type of model we can use to conveniently talk about productivity?

Read More
Great PM Techniques Team Issues

When is 1+1+1>3?

Over the past 2 months, I have been flat-out, head-down, blinkers-on, building a new course…. while still working every day on my own program. (I am still an active program manager).

The course I’ve been working on is about teams – I’m in the middle of building an easy-to-follow process to help transform project teams into a highly productive, effective and happy group of busy people. Pipe dream? I hope not.

The problem I see is that there is a lot of information for project managers that help us work out what management products are required and what steps we need to take to run a project. But while they obviously recognise teams, there is little about team people-management within the project guidance; specifically, little about how to improve the team once you have them established. You are left to work that out yourself or study psychology – and there is plenty to study to be a good PM as it is.

There is loads of stuff on leadership, but except in a few cases, I find that most of the leadership information is not directly aimed at project managers. So where is a simple source about how to understand and manage your team? Stuff you can apply every day.

The thing is, it takes a lot of experience, maturity and a touch of behavioural psychology to work with a team of individuals who have come together for no other reason than to build products together under a project. It’s a big ask, and we are not all equipped to do it – especially when we start out. Many of the people in the team may be older than we are, used to doing things their way or come with their own “rules of engagement”.

I recall being a junior team leader at 19. Admittedly not a project team then, but still a team leader. I had to assign tasks to people who were mostly way older than myself. I had to set up rosters, handle people not turning up for work, and even worse – turning up under the influence of a long day at the pub (it was a night-time job). (I even at one stage had to dismiss my best friend that worked there with me). It’s tough.

When you start out, you think you have authority by virtue of your role, and maybe you do, but it’s fleeting authority.

You see, you earn the right to lead: having been given the role, people “grant” you the “right” to lead them. Then as well as that, they accept each other as fellow workers. Sure makes for a complex situation!

Do you find that your days often consist of trying to work out what people in the project are actually up to? Or are your forever trying to work out how close to their previously agreed, or now overdue targets they actually are?

Do you find you have to play the pacifier between bickering team members? Constantly needing to have heart to hearts with distressed or upset team members? Do you have the boss or the sales guys on to you because of a lack of product delivery they can talk about? Or stakeholders making promises that bear no similarity to the team’s reality? Or cultural differences playing havoc with your communications. Or simply lazy, uninspired people?

Well, imagine a different scenario….

Read More
Great PM Techniques Planning Team Issues

Common Project Team Issues #1: Commitment to Targets

Why won’t my team commit to a target?

Does this sound like your team? Believe me, you are not alone. But there are really simple things we can do to help make your task of herding the cats easier… Lets look into them.

The Symptom

No matter how hard you try, your team members don’t want to work to a project plan target even if pressured with extra incentives like over time pay, benefits etc.

They won’t go the “extra mile” to meet an expected or promised target if it looks like getting behind.

When presented with a plan that has been supported by the boss or owner, those people who have been assigned tasks will usually say in a team meeting something along the lines of (any or all of the following…

“I think I can do that but no guarantees”

“I still have this and that to do, and I have leave coming up”

“It’s too difficult, no one can do it in that time”

“I have to help Joe in the xyz team”,

or my favourite:

“Everything those other guys have done I have to just undo and do it again – it will take me weeks ….”

You know those types of conversations. To you they just sound like excuses, to them, they are reasons.

Read More
1 2