Project Management

The people side of project management

Project management isn't just about delivering on time, scope, budget and quality. It's about developing people - teams and individuals - let's explore that a little more!

About this Blog


Recent Posts

The great certification debate

Matrix resourcing

The dedicated resource structure

Maximising the return from your project structure - your input is needed!

Emergency 911

The great certification debate

Categories: Career

As you can see my attempt to post more frequently isn't going so well!!

I did create quite a stir this month though in one of my articles -

I knew that this would be an emotive subject, but I wasn't quite prepared for the number of comments and e-mails that I got - a big thank you to everyone who took the time to comment - your feedback is very much appreciated.

I wrote the article from a PMP standpoint in recognition that the PMI is the certification body that is most relevant to the majority of Gantthead members - though by no means all.  I could make the same argument for any other solely exam based certification though - the lack of a capability element will always leave the qualification open to 'gaming' a pass.

Based on the level of replies though, I want to take this a little further, so let's ask some more questions.  For a start, why did you take your PMP (or are you studying for it) - was it for yourself, for your employer (current or potential), something else?  When you had the qualification, how important were the PDUs - did you see the importance or was the exam pass enough?  In pursuing your PDUs is that an exercise in making the numbers or is it an opportunity to advance your knowledge?

I'll be honest, I took the PMP for career reasons - I was one of those people who didn't think I needed it because my reputation and experience spoke for themselves - it seems slightly arrogant looking back.  When I was considering starting my own consulting firm then I had to be pragmatic about the standards that the market demanded, and PMP was it.

I don't find the PDUs onerous - in fact the hardest part is actually remembering to register them with the PMI.  In part that may be because I can claim PDUs for my articles here on Gantthead - in fact if I have a complaint about the PDU process it's that I am given a set number of PDUs for a published article, even if the work didn't take that long.

What about you?

How do you answer these questions?

And for those of you that have experience with IPMA or national qualifications - what are your experiences - what do you like, what do you dislike?

Posted on: July 28, 2008 03:36 PM | Permalink | Comments (27)

Matrix resourcing

First off - an apology.

It's been way too long since my last post, work has been crazy but I'll try and make my contributions somewhat more regular.

In the last item I looked at the dedicated resource model, and in this entry I want to close the loop on this little piece by talking about matric resourcing.  This is obviously the most common model these days, with resources being assigned to projects as needs arise.  These resources may have operational roles or may be seconded from other project areas, but the key is that they aren't a dedicated team.

This can be a double edged sword - you trade the ability to have SMEs on your project team which should serve to increase the functional knowledge on the relevant areas within the project team, however the trade off is that people aren't necessarily used to working together as a team.

Consider a sports analogy - we can all think of examples in our favourite sports where teams have brought in high priced stars who have proved to be incapable of working as a single cohesive unit - the whole is considerably less than the sum of the parts.

Of course this isn't always the case, but as project managers we need to be very careful when managing matric teams.  We have to be careful to ensure that the individuals are working together and that the needs of the project are paramount at all times.  The PM needs to undertake formal and informal team building exercises - it may not be anything more than rotating the chairing of the weekly status meeting, but make sure that people feel part of the project team, if only for a fixed period.

The matrix structure has a number of distinct advantages for team members if managed well.  Team members have a chance to work with different people than would otherwise be possible, and they will have an opportunity to develop different skills.  Additionally they will be exposed to other areas of the organisation and that will inevitably help build a more rounded employee.
Posted on: July 03, 2008 11:13 AM | Permalink | Comments (5)

The dedicated resource structure

Categories: Leadership

In the last post, I introduced the two main types of resourcing models that I see - either dedicated resources or the matrix model that we are all familiar with.  The matrix is definitely more common, but I'll talk about that one next time.  In this post let's look at the dedicated resource model.

This generally only works if there are always a significant number of projects going on, but software development is a fairly common example of this model.  Each new product, and potentially each new release is a major project, so the concept of having dedicated resources for projects can work well.  That doesn't mean that every project uses exactly the same team - there will be differences in the weighting of front end vs. back end work which will change the balance of each team slightly, but in principle the PMO controls all project resources - allocating them across initiatives, monitoring skills shortages and addressing training, etc.

Here's my main problem with this model - it's structured more for the benefit of the organisation (at least in the short term) than for the individual.  Dedicated project resources creates silos - core project teams see very little change and that means that the people on those teams lose a sense of belonging to the larger company if you aren't careful.  In the short run these projects are much more efficient - people know how to work with one another, they are functional experts on their projects and they can hit the ground running.  In the long term though there is a significant danger that morale will drop, staff turnover will increase, etc.  In addition, the impact of those changes will be more significant than in a matrix structure where you don't relay so heavily on individuals to be the experts - the expertise is more widely spread across multiple resources.

In some ways you can mitigate these risks by cycling people through support and maintenance roles on the product that has just been released, but that has its own challenges - staff who have just spent months working on leading edge development for a new piece of software may not be thrilled at going on to a role of dealing with help desk tickets.

From a corporate side the argument against dedicated teams is that functional managers lose control over resources - handing it off to the PMO and the PMs.  I would argue that is more of a theoretical problem rather than a real one if you have a well structured, well skilled PMO, but I understand the concept.

Does all this mean that the dedicated project team model is dead?  Not necessarily, but it is a fairly specialised model for specific circumstances.  Do you still see it, or has it disappeared in recent years?

Posted on: June 01, 2008 11:16 AM | Permalink | Comments (1)

Maximising the return from your project structure - your input is needed!

Categories: Skills Development

One of the more often asked questions I face is along the lines of "what kind of PMO should I develop?", or "should I have dedicated project resources, or rotate people in from one project to the next?"

My answer is always the same - it depends.  There is no single structure that will guarantee success, you need to structure your project resources in a way that integrates with the rest of your organisation.  It doesn't matter what that structure is as long as it works in support of everything else and not against it.

From a people standpoint, what's far more important is to get the most out of the people regardless of the structure that they find themselves in.  If you have the same people dedicated to every project then you need to focus the effort on ensuring that they grow as much as possible from one initiaitve to the next.  If on the other hand you have people swapping in and out then you need to ensure that the best practices from one are shared with the new people and that people don't suffer a skills drop in the time period that they aren't actively involved in projects.

Over the next couple of entries I'm going to explore each of these situations in a bit more detail, but before I do I need your help.  Which of these situations do you most relate to, what problems does your project / PMO structure cause and how do you overcome them?

Let me know and then let's explore the solutions together,

Posted on: May 20, 2008 01:13 PM | Permalink | Comments (4)

Emergency 911

Categories: Leadership

One of my current clients has a lot of small, ad hoc requests that need to be completed by the development team.  We've introduced a process and SLA for tracking and executing these requests, but it doesn't always stick.

It's not unusual to get 'Emergency 911' requests that sound something like "we have to complete this by the end of today or one of our major partners is going to be upset with us".  Now I'm tempted to fall back on the old adage of 'a failure to plan on your part does not constitute an emergency on mine', but the mature, collaborative side of me (!) refrains.

The argument is that the client department making the request received it late and therefore couldn't give us the time that we really need.  That may be true, it may not - at the end of the day it doesn't really matter.

We have all been in these situations, and of course, we always do what we can to accommodate the requests, but we need to understand the impact that this has on our teams.

Aside from the fact that it causes upheaval on their existing project tasks, this culture of multiple small 'tweaks' creates an operational culture rather than a project culture and that can cause confusion in your project teams.  It also leads to lower quality project work as people are constantly stopping and starting what they are doing - and we haven't even started talking about schedules...

The nature of the team that I am working with makes it difficult to completely segregate these minor 'operational' changes and assign them to a separate team, but it is important that we work with our business clients to help them understand that there can be significant downstream impact beyond just asking a resource to stay late.  In my particular example it is going to take a big investment of time and effort to bring the organisation to a point of realising that the ability to plan ahead, move to packaged releases for all changes, etc, but that the investment absoultely has to be made.

I'm working with a very tactical organisation, and the move to a strategic organisation is going to be long and hard, but ultimately worthwhile.

Posted on: May 12, 2008 01:01 PM | Permalink | Comments (6)

"Always do right. This will gratify some people and astonish the rest."

- Mark Twain