Week 15 – The price of Trust
Pretty amazing thought, but I’ve been noticing just how valuable trust is and how expensive distrust is.
Think about how much easier it is to work and interact with those you trust versus those whom you either distrust or who you just don’t trust as much. I think in the working environment, this can be greatly influenced by the management team. I was fortunate to work in a company where trust was an integral part of the culture and in others where CYA was the norm. I got a lot more work done in the former than the latter.
Trust impacts a lot of areas of your work life. The biggest and most obvious I think is communication. There is a completely different level of communication with those you trust and those you do not trust. Communication with those you trust is often less formal and overall richer in content. You are more likely to have a face to face with those you trust (you probably like them more). Face to face is the richest form of communication; you convey much more than just the words. You can communicate greater range of meaning and emotion.
On the other hand, those you do not trust are more likely than not to get an email. Probably one that has a few cc’s – just in case. The email is likely to be very factual and directive – “I need such and such by Tuesday.” You’re unlikely to convey emotions (emoticons not withstanding) or any richer channels – you probably even avoid verbal communications.
OK, yes I am talking about myself as well. I find that distrust leads to more distrust and avoidance and thus non-communication and ultimately ineffectiveness which hurts everyone and your project. Therefore, I conclude that it is counter-productive to distrust someone – regardless of their prior behavior. So, I can’t remember who said it, but the motto goes “trust, but verify.”
I’m going to work on adopting that. It is unprofessional for me not to verify and ensure that what is committed is done, but at the same time it is unprofessional (and unproductive) for me to go on the assumption that it will not be done, or not done well. I think I will save a lot of time and heartache personally.
Let me suggest then that trust is not earned it is given, and that we should give it freely and constantly to those we work with. Yes, just like Charlie Brown always going for the field goal with Lucy holding the ball. If you are in an un-trusting work relationship, it is time to take the first step – just like I will on Monday.
Saturday, December 30, 2006
Week 14 (Building a Program Management Office)
Week 14 – Change Control, Capacity and Budget
As I look at our projects, we have about 15 months between now and final implementation. We also have all our requirements completed, defined and ready for programming. All this is great, but I’ve been thinking a lot about our ability to make changes (mostly scope) over the remaining time.
In looking at this, the first question is: What is our capacity for change? I think this has to be determined based on resources, schedules, lead times, budgets and the like. We may actually have the capacity to make a 180 degree change, or a series of changes that add up to that. In any case, I think each project must have some “change limit” – this being the amount of change that can be absorbed within the time and budget available.
The first existing method that comes to mind for managing change is the management reserve budget. The intention of this is primarily to deal with risks, but something similar might be arranged for change. Maybe a change reserve budget. This would then define the capacity for change up front and allow us to track against that capacity. I think that we could then add something called a “change rate” to allow us to better allocate that capacity across the project.
The rate of change would naturally (I think) have to decrease over the course of the project. So that while we might have the capacity to make say $100,000 worth of changes, we could not reasonably make all of those changes at once, nor would it be possible to make them all at the last minute.
I think that the rate would have to continually decrease across the duration of the project, and at some point (depending on methodology, flexibility, resources, etc) the project would not be able to sustain any changes - we used to call this “the freeze.” I think then that our change model would look something like that below:
I have not figured out how to determine a good rate, but the idea here is that we pace ourselves with our changes, and that if we try to make too many at any one point, we end up overloading the project- impacting dates, etc.
I know that the traditional model of change control is that we always assess the impact and elevate that to the “powers that be” for a decision on whether we can do the change or not. But experience has shown that we often end up making certain changes and not changing any dates. How many times have you heard “it’s only a week, can’t you absorb that in your 10 month project?” Well yeah, I did absorb the first 12 one-week changes, but this is lucky 13. Now with a “rate” or speed limit, you can schedule the changes, or push back if there is too much at any given time. One way might be to say that we can only accept X amount of changes for the next cycle / month / period.
I think that the concern I am looking to address is the tendency to use up our entire change budget at the beginning of a project and get ½ way through with nothing left. If we use the rate as a limit, then we can actually have the ability to make changes later in the project when they’re needed.
Another idea I hear was about prioritizing changes, I worry about this for the simple reasons that if you only have one change, then it is top priority. Then after you put that in the next change that comes up will be top priority. The priority system is useful when you have all the information in front of you, but with change, you don’t know what is over the horizon. If you did, you would have planned for it and it wouldn’t be a change and you wouldn’t need to prioritize it.
So I think the answer is to pace yourself. Whether you are running a marathon or a sprint, if you use up all your energy too early, you’re in for a hard time. If we use the change rate, then we know we will have the ability to handle at least some part of what is coming.
Of course, I have no idea how to determine a change rate, and as I think more, I realize that this will create a backlog of changes – which we can then prioritize! Hmmm
As I look at our projects, we have about 15 months between now and final implementation. We also have all our requirements completed, defined and ready for programming. All this is great, but I’ve been thinking a lot about our ability to make changes (mostly scope) over the remaining time.
In looking at this, the first question is: What is our capacity for change? I think this has to be determined based on resources, schedules, lead times, budgets and the like. We may actually have the capacity to make a 180 degree change, or a series of changes that add up to that. In any case, I think each project must have some “change limit” – this being the amount of change that can be absorbed within the time and budget available.
The first existing method that comes to mind for managing change is the management reserve budget. The intention of this is primarily to deal with risks, but something similar might be arranged for change. Maybe a change reserve budget. This would then define the capacity for change up front and allow us to track against that capacity. I think that we could then add something called a “change rate” to allow us to better allocate that capacity across the project.
The rate of change would naturally (I think) have to decrease over the course of the project. So that while we might have the capacity to make say $100,000 worth of changes, we could not reasonably make all of those changes at once, nor would it be possible to make them all at the last minute.
I think that the rate would have to continually decrease across the duration of the project, and at some point (depending on methodology, flexibility, resources, etc) the project would not be able to sustain any changes - we used to call this “the freeze.” I think then that our change model would look something like that below:
I have not figured out how to determine a good rate, but the idea here is that we pace ourselves with our changes, and that if we try to make too many at any one point, we end up overloading the project- impacting dates, etc.
I know that the traditional model of change control is that we always assess the impact and elevate that to the “powers that be” for a decision on whether we can do the change or not. But experience has shown that we often end up making certain changes and not changing any dates. How many times have you heard “it’s only a week, can’t you absorb that in your 10 month project?” Well yeah, I did absorb the first 12 one-week changes, but this is lucky 13. Now with a “rate” or speed limit, you can schedule the changes, or push back if there is too much at any given time. One way might be to say that we can only accept X amount of changes for the next cycle / month / period.
I think that the concern I am looking to address is the tendency to use up our entire change budget at the beginning of a project and get ½ way through with nothing left. If we use the rate as a limit, then we can actually have the ability to make changes later in the project when they’re needed.
Another idea I hear was about prioritizing changes, I worry about this for the simple reasons that if you only have one change, then it is top priority. Then after you put that in the next change that comes up will be top priority. The priority system is useful when you have all the information in front of you, but with change, you don’t know what is over the horizon. If you did, you would have planned for it and it wouldn’t be a change and you wouldn’t need to prioritize it.
So I think the answer is to pace yourself. Whether you are running a marathon or a sprint, if you use up all your energy too early, you’re in for a hard time. If we use the change rate, then we know we will have the ability to handle at least some part of what is coming.
Of course, I have no idea how to determine a change rate, and as I think more, I realize that this will create a backlog of changes – which we can then prioritize! Hmmm
Thursday, December 14, 2006
PMO Staffing (short)
Many PMOs today are made up of teams of professional, dedicated Project Managers who are assigned to projects throughout their organizations. One job of the PMO is to put the right PM with the right project at the right time. Because of the nature of projects, this can be VERY tricky. Even the best resource management can be inadequate when a project gets into trouble, or when several projects get behind schedule.
Staffing is also prime target of politics. Without a project prioritization system, the assignment of project managers can (and often will) be viewed as arbitrary, unfair, or biased. One way to counter this perception is to be scrupulously independent in everything you do. It will not help all the time, but being know as fair and unbiased in the little things will serve you well when it comes time for the big decisions.
Another staffing political pitfall is more subtle. In these situations, one group starts requesting a specific PM. If Joe did well for Accounting in the last project, then they will probably be asking for Joe again. They will hit you with pleas like “he already knows everyone here”, or “he’s familiar with the way we work”, and more. It sounds immanently logical and that’s the trap. Going down this path will turn Joe into “the Accounting PM.” And if Accounting has their very own PM why can’t everyone else? And why isn’t Accounting paying for him? And finally, why doesn’t he just report to accounting and we’ll get rid of the PMO?
So be careful how you staff your projects and keep the long view in mind – someone has to.
Staffing is also prime target of politics. Without a project prioritization system, the assignment of project managers can (and often will) be viewed as arbitrary, unfair, or biased. One way to counter this perception is to be scrupulously independent in everything you do. It will not help all the time, but being know as fair and unbiased in the little things will serve you well when it comes time for the big decisions.
Another staffing political pitfall is more subtle. In these situations, one group starts requesting a specific PM. If Joe did well for Accounting in the last project, then they will probably be asking for Joe again. They will hit you with pleas like “he already knows everyone here”, or “he’s familiar with the way we work”, and more. It sounds immanently logical and that’s the trap. Going down this path will turn Joe into “the Accounting PM.” And if Accounting has their very own PM why can’t everyone else? And why isn’t Accounting paying for him? And finally, why doesn’t he just report to accounting and we’ll get rid of the PMO?
So be careful how you staff your projects and keep the long view in mind – someone has to.
Saturday, December 02, 2006
Week 13 (Building a Program Management Office)
Well full week back after the Thanksgiving break. This was another travel week as we installed a PM at one of the project locations. The PMO has now doubled in size to two!! I think the new PM will work out great as she is working in the location where all the business teams are located and those are the people who have to live with what we implement.
This week did once again cause me to think about roles and identities. What is the PMO? What is a project manager? It’s easy to say “it depends”, but when there are people and projects involved, we need to have a clear definition. I have already learned that if there is more than one boss, there is more than one definition of your role. This is doubly true for consultants.
In bringing on the new PM, I am concerned that she is being under (used/appreciated?). In this case, the PM is certainly capable of managing a large part of the project and she could certainly provide some very useful advice and counsel to the leadership team. Because of the perceptions, this is just not likely. The perception is that the PM is there to do the support work, and that’s it. I brought the new PM to the board meeting and I was asked by the business lead why I brought her –as in “she is not this level so she doesn’t need to be here.” This pretty much defined at least our starting point.
Again, it comes down to people and I have a real problem here. Clearly, we (the PMO) were brought on because of our knowledge and experience, yet this is rarely sought and often unwanted. Why would anyone seek a particular set of expertise and then ignore it or leave it on the shelf. It is like buying a high-powered computer and doing nothing but web surfing. Strange, what does this mean? Well I have a theory.
I think that the problem is one of comfort and understanding. Using the high-powered computer example, if all you know is web surfing, then that is what you’ll do. They see the computer as just able to web surf faster and better, and do not see that they can produce multi-media presentations or do their taxes or run a small business – or even better – play the latest graphics-intensive games. So the challenge there is to raise awareness. The second challenge is to make them comfortable with the tools and techniques of project management. So how do I go about that???
Well, first thought is that I have to become more assertive and aggressive. I can’t play a passive and supporting role; I have to take an active and leadership role. And that will certainly piss someone off. I don’t seem to be having a lot of luck in the persuasion department, so I’m going to take some things on myself (more work, but hopefully more success) and I’m going to push for some other things. One of which will be to have full-blown planning session for one of the projects – that could be successful, but not if everyone comes in with a bad attitude – which they will if I do this wrong. Well, this is the time of year when everyone is supposedly in a good mood; maybe I can leverage some of that. Ho Ho Ho.
This week did once again cause me to think about roles and identities. What is the PMO? What is a project manager? It’s easy to say “it depends”, but when there are people and projects involved, we need to have a clear definition. I have already learned that if there is more than one boss, there is more than one definition of your role. This is doubly true for consultants.
In bringing on the new PM, I am concerned that she is being under (used/appreciated?). In this case, the PM is certainly capable of managing a large part of the project and she could certainly provide some very useful advice and counsel to the leadership team. Because of the perceptions, this is just not likely. The perception is that the PM is there to do the support work, and that’s it. I brought the new PM to the board meeting and I was asked by the business lead why I brought her –as in “she is not this level so she doesn’t need to be here.” This pretty much defined at least our starting point.
Again, it comes down to people and I have a real problem here. Clearly, we (the PMO) were brought on because of our knowledge and experience, yet this is rarely sought and often unwanted. Why would anyone seek a particular set of expertise and then ignore it or leave it on the shelf. It is like buying a high-powered computer and doing nothing but web surfing. Strange, what does this mean? Well I have a theory.
I think that the problem is one of comfort and understanding. Using the high-powered computer example, if all you know is web surfing, then that is what you’ll do. They see the computer as just able to web surf faster and better, and do not see that they can produce multi-media presentations or do their taxes or run a small business – or even better – play the latest graphics-intensive games. So the challenge there is to raise awareness. The second challenge is to make them comfortable with the tools and techniques of project management. So how do I go about that???
Well, first thought is that I have to become more assertive and aggressive. I can’t play a passive and supporting role; I have to take an active and leadership role. And that will certainly piss someone off. I don’t seem to be having a lot of luck in the persuasion department, so I’m going to take some things on myself (more work, but hopefully more success) and I’m going to push for some other things. One of which will be to have full-blown planning session for one of the projects – that could be successful, but not if everyone comes in with a bad attitude – which they will if I do this wrong. Well, this is the time of year when everyone is supposedly in a good mood; maybe I can leverage some of that. Ho Ho Ho.
PMO Support Function (short)
Support PMO services are often referred to as administrative functions, and may be considered “menial” or “trivial”. Nothing could be further from the truth.
A PMO provides support services to assist with the management of a project. The key differentiator between support and project management is that support is not a managerial role. A supporting team member will often update the schedule, run meetings, follow up on open issues and other similar tasks, but they will not have the responsibility or authority to make project level decisions. Supporting on a project is often a good role for junior PMs, showing them the processes and placing them with a more seasoned PM for mentoring.
Support is the hard part of project management and it is what often meets the most resistance. Team members do not want to take minutes, track issues and action items, produce reports and so on. As with all clouds, this one has a sliver lining and becomes one of the keys gaining project management acceptance.
If you – the PMO – perform the support function, your stakeholders can realize the value of project management without incurring the cost. This will open a lot of doors and minds. Providing exceptional project support then is one of the first steps in building a great PMO.
A PMO provides support services to assist with the management of a project. The key differentiator between support and project management is that support is not a managerial role. A supporting team member will often update the schedule, run meetings, follow up on open issues and other similar tasks, but they will not have the responsibility or authority to make project level decisions. Supporting on a project is often a good role for junior PMs, showing them the processes and placing them with a more seasoned PM for mentoring.
Support is the hard part of project management and it is what often meets the most resistance. Team members do not want to take minutes, track issues and action items, produce reports and so on. As with all clouds, this one has a sliver lining and becomes one of the keys gaining project management acceptance.
If you – the PMO – perform the support function, your stakeholders can realize the value of project management without incurring the cost. This will open a lot of doors and minds. Providing exceptional project support then is one of the first steps in building a great PMO.
Subscribe to:
Posts (Atom)
