Discussion on:
View:
Show:
My experience with Accidental project managers is that they always want to things "their way" instead of working as a team to try and standardize forms, templates, etc.
One of the most difficult tasks that the project manager has to do is strike the delicate balance between taking everyone with him (consensus/ team spirit) and meeting deadlines which often will force him into being a little assertive. What is needed is a trust among all the project team members and the project manager.
can be easily achieved, if the project manager is one that came up through the ranks.
In any team the members will each have one area they are stronger in, if the project manager knows this, and which area each team member is best in, then put them in charge of that section of the project, where all other team members have to accept their input as law.
this is also called a "Flat" Managment style, and it treats all team members as equal in importance, with each leading in the area they excel in.
this keeps trust and respect and team morale high as all members know their input is valued.
the high morale improves team output, in quality and reduces time as the efficiency improves.
In any team the members will each have one area they are stronger in, if the project manager knows this, and which area each team member is best in, then put them in charge of that section of the project, where all other team members have to accept their input as law.
this is also called a "Flat" Managment style, and it treats all team members as equal in importance, with each leading in the area they excel in.
this keeps trust and respect and team morale high as all members know their input is valued.
the high morale improves team output, in quality and reduces time as the efficiency improves.
I think you've pegged a key point here - trust is critcal. I have worked on teams where we don't have trust, and it makes everything a lot harder to do, and it's also very demotivating.
It seems as if far too many people are reading the PMBOK and instantly know what they are doing. Better yet they can advise everyone else on what makes a good PM.
Whenever I interview a candidate for a PM position, there is one question that I also ask. If you had to chose one thing, what would be the most important thing in project management?
Anyone?
Whenever I interview a candidate for a PM position, there is one question that I also ask. If you had to chose one thing, what would be the most important thing in project management?
Anyone?
...Communication. If you can't communicate effectively, it doesn't matter how well you know the PMBoK. Commumication leads to better understanding of user requirements, team building, etc.
Three things I ask when interviewing PMs:
1. Does the PMP make you a better project manager? If so, why. Careful, this is a trick question.
2. What makes a project successful? Looking for more than on time and within budget here.
3. Why would your project team want to work on another project you are managing? It's all about the soft skills.
Hope I passed your challenge.
Three things I ask when interviewing PMs:
1. Does the PMP make you a better project manager? If so, why. Careful, this is a trick question.
2. What makes a project successful? Looking for more than on time and within budget here.
3. Why would your project team want to work on another project you are managing? It's all about the soft skills.
Hope I passed your challenge.
I would it is the ability to get along with people...they are the ones who make it happen for you....and you don't get that from the PMBOK. Knowing when you are annoying people is also very good to know.
I think the most important trait in a PM is that he/she recognize that they know they don't know everything.
I have come across many projects that are out of control and doomed to failure because of the pride of the PM. They want to prove to the world that they can do it all and know it all.
I find the most successful project managers rely on their "management" skills and let the developers / engineers / designers etc... take the lead where appropriate. This way you avoid PM's that cause project chaos because they thought they were better at Java engineering than the lead developer.
*Note: Out side of that quality, if you candidates don't understand the phases of a project and what deliverables go with each phase....
I have come across many projects that are out of control and doomed to failure because of the pride of the PM. They want to prove to the world that they can do it all and know it all.
I find the most successful project managers rely on their "management" skills and let the developers / engineers / designers etc... take the lead where appropriate. This way you avoid PM's that cause project chaos because they thought they were better at Java engineering than the lead developer.
*Note: Out side of that quality, if you candidates don't understand the phases of a project and what deliverables go with each phase....
The most important thing in project management is Project Risk Management. All the standards/development process that have cropped up during the recent times are only to make sure that the project is successfull. And Risk Management is the only knowledge area which addresses issues that can screw up the project. So I strongly feel that riskmanagment is the most impoprtant thing in Project Management.
good article. worth expounding more and raised to a more technical discussion level.
I can't say I agree with the definition of "good" in this article. What they descripe as good would not be acceptable in the organizations I have worked in. What the article classifies as "proactive" is closer to good.
As someone who has become an "accidental" project manager based on my technical abilities, my interpersonal skills and my drive to provide clients with a high quality application, I am just starting to make the transition between reactive and proactive management.
I'm also understanding the need to manage client expectations and to provide them with the solution that works for them, not the solution that makes the most sense from a purely technical perspective.
The need to provide the level of quality that the client expects rather than the highest level possible is not something I have entertained before. In my (limited) experience, it seems that the clients always want the absolute best quality solution. Is this just the clients I've worked with? Or am I missing something when interpreting their expectations?
Thanks for the insight.
I'm also understanding the need to manage client expectations and to provide them with the solution that works for them, not the solution that makes the most sense from a purely technical perspective.
The need to provide the level of quality that the client expects rather than the highest level possible is not something I have entertained before. In my (limited) experience, it seems that the clients always want the absolute best quality solution. Is this just the clients I've worked with? Or am I missing something when interpreting their expectations?
Thanks for the insight.
I don't think it's just your clients - this is the classic dilemma of Project Management everywhere (not just in IT).
One of the key concepts in the formal PM "canon" (the stuff that led to PMPs and all) is that there's three elements that interact: scope, time, and cost. Sometimes this is thought of as three sides of a triangle, or three legs of a stool - to show how these elements are always inter-related.
The idea is that if you change one of these (increase scope, shorten the project timeline, etc.), the other ones WILL be impacted.
In terms of user expectations, one of the challenges for a PM is to make this tradeoff clear. Doing this is less a technical issue than a people issue, especially if your clients are not used to managing trade-offs.
As a PM, you need to be aware of this too. If as a former techie, you are used to providing top-quality products, that can have the effect of increasing the scope of your projects (since higher quality means more work). If your clients don't want that quality level, then they are saying they are willing to accept a smaller scope, which may give them some other benefit they want (lower cost, quicker delivery).
Even if your clients aren't making this tradeoff consciously, it shows that PMs need to be clear what clients want, and be willing to change their own expectations and desires to meet the clients needs.
One of the key concepts in the formal PM "canon" (the stuff that led to PMPs and all) is that there's three elements that interact: scope, time, and cost. Sometimes this is thought of as three sides of a triangle, or three legs of a stool - to show how these elements are always inter-related.
The idea is that if you change one of these (increase scope, shorten the project timeline, etc.), the other ones WILL be impacted.
In terms of user expectations, one of the challenges for a PM is to make this tradeoff clear. Doing this is less a technical issue than a people issue, especially if your clients are not used to managing trade-offs.
As a PM, you need to be aware of this too. If as a former techie, you are used to providing top-quality products, that can have the effect of increasing the scope of your projects (since higher quality means more work). If your clients don't want that quality level, then they are saying they are willing to accept a smaller scope, which may give them some other benefit they want (lower cost, quicker delivery).
Even if your clients aren't making this tradeoff consciously, it shows that PMs need to be clear what clients want, and be willing to change their own expectations and desires to meet the clients needs.
I know a lot of "good" project managers, who work diligently under the "good" parameters, only to oversee projects that fail in one way or another (time, budget, quality, communication, client satisfaction, ...). Project success hinges on more than just completion. Therefore, just to be a "good" project manager is not always Good Enough.
Hmmm... Seems we need clarification on what is "good"? For the Satanist, they believe Satan is "good"...
I am not sure I understand why the article needed to take a cheap shot at project managers who are promoted from within.
The article defines three types of project manager, but the only distinguishing characteristic of the "Accidental Project Manager" is that he has arisen from the ranks. No mention is made of where "Good" or "Proactive" managers come from; discussion here is focussed on how the work is done.
I don't think promotion from within is the intended focus of this article, so it seems out of place to have a gratuitous insult in the lead in.
The article defines three types of project manager, but the only distinguishing characteristic of the "Accidental Project Manager" is that he has arisen from the ranks. No mention is made of where "Good" or "Proactive" managers come from; discussion here is focussed on how the work is done.
I don't think promotion from within is the intended focus of this article, so it seems out of place to have a gratuitous insult in the lead in.
We all rise from the ranks, like it or not. You do not come out of school and be an A class PM from the get go. The first "real" project you have to deliver will cause (force) you to learn and you will inevitably lift yourself to the next level (irrespective of any training, although, sure that should help).
At the end of the day, you need to realize that not everyone is (or wants) to be a project manager and as you get older you may not want to hit this stuff every day - it does get old eventually ..
This is from someone who didn't (know he wanted) to be a PM, did it for longer than I care to remember and sees all this certification stuff and wonders how much good it does ..
Go and do it ..
At the end of the day, you need to realize that not everyone is (or wants) to be a project manager and as you get older you may not want to hit this stuff every day - it does get old eventually ..
This is from someone who didn't (know he wanted) to be a PM, did it for longer than I care to remember and sees all this certification stuff and wonders how much good it does ..
Go and do it ..
I don?t think Tom intended to insult people who rise from the ranks. But it is generally true that many start off as technicians (or even as business users) and find themselves required to manage a project.
And, as other contributors to this forum have said, many find we are lacking in one aspect or another, and some people are obviously more suited to the role of project manager than others. Technicians often do not do very well because of their lack of ?soft skills?, which is a large part of project management.
For this reason PMI and other bodies have collated information which is intended to provide the tools for someone to manage projects successfully. This information has been consolidated in the Project Manager?s Body of Knowledge, which covers scope management, time (schedule) management, quality management, cost management, risk management, human resource management, communications management, procurement, and the integration of all these functions (note that other contributors have mentioned some of these topics). This should be supplemented by a process methodology such as found in PRINCE2.
Why reinvent the wheel? If we do not learn from others we are often doomed to make the same mistakes. Grab a copy of PMBOK! Attend a course or two! Read forums like this one.
True, just as having a driving licence does not mean one can drive well or even drive properly, having project management certification does not guarantee one practices the principles. And some people drive quite well without holding a licence!
I started off as an applications programmer, then a systems programmer (remember something called Assembly language?) and was managing projects (not so very well) before I even knew the term. Over the years I learnt some tricks of the trade and became a fulltime project manager before moving into training (of project managers).
Everything brought up in this forum so far is covered in our courses, and a lot of good stuff has been brought up. I read these forums to see if there is something I can learn, too. (Woof, woof!)
And, as other contributors to this forum have said, many find we are lacking in one aspect or another, and some people are obviously more suited to the role of project manager than others. Technicians often do not do very well because of their lack of ?soft skills?, which is a large part of project management.
For this reason PMI and other bodies have collated information which is intended to provide the tools for someone to manage projects successfully. This information has been consolidated in the Project Manager?s Body of Knowledge, which covers scope management, time (schedule) management, quality management, cost management, risk management, human resource management, communications management, procurement, and the integration of all these functions (note that other contributors have mentioned some of these topics). This should be supplemented by a process methodology such as found in PRINCE2.
Why reinvent the wheel? If we do not learn from others we are often doomed to make the same mistakes. Grab a copy of PMBOK! Attend a course or two! Read forums like this one.
True, just as having a driving licence does not mean one can drive well or even drive properly, having project management certification does not guarantee one practices the principles. And some people drive quite well without holding a licence!
I started off as an applications programmer, then a systems programmer (remember something called Assembly language?) and was managing projects (not so very well) before I even knew the term. Over the years I learnt some tricks of the trade and became a fulltime project manager before moving into training (of project managers).
Everything brought up in this forum so far is covered in our courses, and a lot of good stuff has been brought up. I read these forums to see if there is something I can learn, too. (Woof, woof!)
I find this article very interesting and timely for me as one aspiring project manager. Being proactive makes a difference, since you are able to plan ahead for and implement what you know will make the project successful with ease, not only because you are being required to do so.
This article is very useful for me and clarify how to become a good enough PM
Proactive is a good principle
Thanks
Proactive is a good principle
Thanks
Being a project manager, I would like to add one more characteristic that I believe is the defining point between a good PM and a very good PM: a good PM successfully applies the hard skills to achieve project success. A very good PM does this as well, but also applies the soft skills necessary to unite the team and manage user expectations.
I've seen too many PMs who have only focused on hard skills, forgetting that the soft skills are 80% of the job; in other words the Management part of project management.
I've seen too many PMs who have only focused on hard skills, forgetting that the soft skills are 80% of the job; in other words the Management part of project management.
I agree 100% with Andy and in fact would submit that it is the "soft-skills" side that will make or break you as a Proactive PM. The very essence of being Proactive means that you are engaged in the process with your cleint/sponsor. Great topic...
I also agree with this. I think a lot of "accidental" PMs are talented techs who moved up because of their work, but in many places that means moving out of a tech role and into a more soft-skill role.
The trick is that some techs are really much better at just tech (the stereotype of techs with weak social skills is not without some merit...). If one of these people becomes an accidental PM, then you will get just this gap in skill sets.
My experience is that this is very likely to piss everyone involved off - the tech/PM, clients, management, team members - but it is very rare to see someone identify this issue and take steps to deal with it.
While I haven't read it, I hear the boook "Leading Geeks" can help make some of these issues clearer for non-tech folks...
The trick is that some techs are really much better at just tech (the stereotype of techs with weak social skills is not without some merit...). If one of these people becomes an accidental PM, then you will get just this gap in skill sets.
My experience is that this is very likely to piss everyone involved off - the tech/PM, clients, management, team members - but it is very rare to see someone identify this issue and take steps to deal with it.
While I haven't read it, I hear the boook "Leading Geeks" can help make some of these issues clearer for non-tech folks...
I came into project management by 'accident', but do not consider myself 'accidental' by this definition. I have managed projects in may industries and in organizations small, medium and large. It is extremely important for me to approach the project manager role with a 'support' attitude. It is my job to support the talent ensuring they have the tools and time necessary to complete their objectives. It is my job to support the client by setting resonable expectations, fully disclosing their rights and resonsibilities, and maintaining constant communication throughout. It is my job to support management by efficiently using resources and maintaining constant communication throughout.
What I did not expect was the resistance I receive at my newest job. I was hired as Network Administrator and praised for my organizational skills. Whenever I tried to introduce the project style of approaching installs and migrations I was absolutely denied. It has taken over a year and a half to slowly integrate projects as the preferred method. Maybe I'm wrong, but I thought anyone who thinks any techincal endeavour through to the end would realize the absolute need for project management!
What I did not expect was the resistance I receive at my newest job. I was hired as Network Administrator and praised for my organizational skills. Whenever I tried to introduce the project style of approaching installs and migrations I was absolutely denied. It has taken over a year and a half to slowly integrate projects as the preferred method. Maybe I'm wrong, but I thought anyone who thinks any techincal endeavour through to the end would realize the absolute need for project management!
Jay, your experience is very typical when trying to implement change. This seems to be especially true in the technical fields. Management's resistance to change most of the time is routed in a preception that they will be losing control. The real challenge for PM's in organizations that are new to Project Management as a structured deciple is to change that mindset. Unfortunitely, building that creability takes time.
My advice (for whatever it is worth) is to stay positive, continue your great attitude towards support, and as has already been stated communication is key...you're on the right track.
My advice (for whatever it is worth) is to stay positive, continue your great attitude towards support, and as has already been stated communication is key...you're on the right track.
My experience has been similar. However, once people start to see the benefits of a project management approach to an implementation as compared to a random, undocumented, fly-by-the-seat-of-your-pants, reactive approach to implementation, the PM approach starts to become the norm and is even anticipated.
I have to disagree - a really good proactive project manager will address the client's NEEDS which is not necessarily the same as the expectations.
Talking about excellence in management and delivery (as important as the former)of projects, a Project Manager is a Project Manager,no trade offs of skills and knowldege with less or more, proactive or not. It is an absolute leadership and competence to manage and deliver the project as per contract and success.
PM Key Factors of Success: delivered schedule-wise, budget-wise, quality-wise, with motivated team, and importantly; achieved the business intent of his project and maintained good relationships with his client, earning him/or his company trust.
Meaning a PM must have a strong leadership with proven soft skills and technical competence.
PM Key Factors of Success: delivered schedule-wise, budget-wise, quality-wise, with motivated team, and importantly; achieved the business intent of his project and maintained good relationships with his client, earning him/or his company trust.
Meaning a PM must have a strong leadership with proven soft skills and technical competence.
I agree that PMs have to understand what clients really need - but they also have to remember they may not know everything, and a PMs idea of the client's needs may not be correct.
As long as you are careful to not assume you know it all, and make sure you keep updating your "working model" of the client's needs, then I think this can work well.
A super proactive PM will know all this, and work with it implicitly, ready to respond and adjust as needed to new info or changes. It's really the flexibility, the willingness to make changes instead of being stuck on one version of "what we know" or "how to do it" that makes the best PMs - and the most successful leaders.
As long as you are careful to not assume you know it all, and make sure you keep updating your "working model" of the client's needs, then I think this can work well.
A super proactive PM will know all this, and work with it implicitly, ready to respond and adjust as needed to new info or changes. It's really the flexibility, the willingness to make changes instead of being stuck on one version of "what we know" or "how to do it" that makes the best PMs - and the most successful leaders.
The PM upon receipt of his appointment and just before kicking off his new project ( either internally or externally), he has to validate the business requirements obtained from the proposal/contract from his client.
Only then that he has to start reviewing or revising the SOW and technical requirements based from this validation. DON?T EVER START A PROJECT W/OU DUE VALIDATIONFROM THE OWNER. Otherwise, your project will have a lot of "nice to have" features.
A well prepared Project Plan in which all considerations about schedule/timeline, costs, issues/risks and its mitigation,communication systems, toll gate reviews with clients and stakeholders; are explicitly establihed. The precision and completeness of your Project Plan will determine the dynamic of your project, and principally your client relationships.
Only then that he has to start reviewing or revising the SOW and technical requirements based from this validation. DON?T EVER START A PROJECT W/OU DUE VALIDATIONFROM THE OWNER. Otherwise, your project will have a lot of "nice to have" features.
A well prepared Project Plan in which all considerations about schedule/timeline, costs, issues/risks and its mitigation,communication systems, toll gate reviews with clients and stakeholders; are explicitly establihed. The precision and completeness of your Project Plan will determine the dynamic of your project, and principally your client relationships.
In an ideal world, the PM will help the client to understand their needs and guide them through the process - assuming you know all ends usually in arrogance (at least that what the client thinks)
That is what your project for- to find a technological solution(s), or alike to achieve their business goal(s).
Now, you have formed your TEAM, from different disciplines, and presumably with mulitple skills; to develop and deliver the project. Though you have a Super Team, you as a PM still need to work many things sinergistically with your client. You can?t avoid that.
And, that?s what the Toll Gates are for - to review your project progress periodically, see if eveything is on-track (and within their expectation), and ask their re-validation/and or approval.And this gating process should be done, recurrently, along the project lifecycle to be in sync with your client always.
And, of course to avoid to be showy and arrogance............
Now, you have formed your TEAM, from different disciplines, and presumably with mulitple skills; to develop and deliver the project. Though you have a Super Team, you as a PM still need to work many things sinergistically with your client. You can?t avoid that.
And, that?s what the Toll Gates are for - to review your project progress periodically, see if eveything is on-track (and within their expectation), and ask their re-validation/and or approval.And this gating process should be done, recurrently, along the project lifecycle to be in sync with your client always.
And, of course to avoid to be showy and arrogance............
Yes, that's just what I was getting at - thanks for cooking it down so nicely!
I was reluctant to use the term arrogance in my comment, because I didn't want to assume the PM was *trying* to be arrogant.
I think part of the issue here is that how you do this depends a lot on the client. Do they know what they're doing? Will they appreciate your asking open questions about why they want this project, or will they think you are second guessing them?
As a result, I think a lot of PMs end up doing the "assessment of client needs" indirectly, by poking around in the specs, asking the users themselves (who rarely are the project sponsors) what they need, etc. And if the gathering info is done "behind the scenes", then odds are the client isn't going to want to be confronted about how their claimed needs don't match reality.
In the end, it's politics and interpersonal relationships that are the key.
(I was furtunate to attend a really good class on "Consulting Skills for the IT Professional", and spent a lot of time on these very messy areas...)
I was reluctant to use the term arrogance in my comment, because I didn't want to assume the PM was *trying* to be arrogant.
I think part of the issue here is that how you do this depends a lot on the client. Do they know what they're doing? Will they appreciate your asking open questions about why they want this project, or will they think you are second guessing them?
As a result, I think a lot of PMs end up doing the "assessment of client needs" indirectly, by poking around in the specs, asking the users themselves (who rarely are the project sponsors) what they need, etc. And if the gathering info is done "behind the scenes", then odds are the client isn't going to want to be confronted about how their claimed needs don't match reality.
In the end, it's politics and interpersonal relationships that are the key.
(I was furtunate to attend a really good class on "Consulting Skills for the IT Professional", and spent a lot of time on these very messy areas...)
Holger, we worked togethet at IBM... I would like to ask you a question.
luc.van.overmeiren@telenet.be
Tx
Luc
luc.van.overmeiren@telenet.be
Tx
Luc
Definitively, I agree with Tom, the point is that in my opinion a Project Manager has to face with the Project in the same way that if it was his own company. There is a lot of things that a project manager has to manage (of course not only the Microsoft Project File :-)), but the word than in my opinion describe a good project manager is "anticipate".
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
