Home
>
gantthead blogs
>
by - Andy Jordan
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!
|
The dedicated resource structure
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?
Geoffrey Kelly says:
At least this view creates the basis for a discussion but I feel sorry for you and I have to ask are in the wrong industry
In my experience both types of models have in the past been looked at but those companies who end up with dedicated resources suffer the most as they remove the flexible working conditions that in these days are a prerequisite
By saying that having dedicated teams "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" is like burying your head in the sand as reality dicates that as PM''s we are adaptable to meet the needs of our companies and therefore the staff need to mirror that demand
Failure to meet these challenges head on will mean a downsizing of teams as for the PMO controlling the teams size and structure this is old fashioned what you need is a resource/delivery manager or a change manager who can read the issue and who knows the staff capabilities then allocates the work accordingly.
The PMO should be the governance and supplier of templates and forms otherwise you will have lots of chiefs and no indians to do the actual work as for them to monitor performance and assess training needs infers that your PMO knows as much as you do if that is the case who needs you?
Get real organisations are structured to get the most out of staff if you think that the individual counts then it is time to move on.
Monday, December 29, 2008 9:00:05 AM EST
Please Login/Register to leave a comment.
sponsored announcements and special offers
You can do this!
Earn your master's degree in project management without putting your life on hold at GoUWP.com!
Apply today at GoUWP.com for 100% online courses, 45 PDUs each. No entrance exam. University of Wisconsin- Platteville’s MS in Project Management is globally accredited by PMI. Combine academics and real-world scenarios for a 360-degree education.
If you have a distributed team, what are you trying to achieve with Agile approaches? Isn't Agile more for co-located teams? There are eight key benefits to working in a distributed Agile environment. A new report from ProjectsAtWork looks at each of those benefits – and how you can achieve them.
Most business and IT executives agree that any company able to rapidly deliver software of high and predictable quality with minimum budgets enjoys a significant advantage. However, practical experience shows that the challenges associated with software quality remain largely unsolved. Download the white paper Uplift Quality with Requirements Driven Testing to learn fundamental principles of Requirements Driven Testing.
|
sponsors
