I've talked to PMs recently who are almost literally crying for feedback from their project teams in order to improve and still get nothing. In organizations with project post-mortem procedures, not reviewing the lessons learned and estimates vs. actual data to come up with recommendations and revised practices for future projects is a terrible waste.
Perhaps because many project teams are eager to be done and move on to the next project, the process is hard to manage. When it is being done, it may be that many organizations feel good about having done the close work and then forget that review, analysis and follow-up is required to get value out of the closing process. Depending on the organization's culture, the issue may be a resistance to change inclusive of any data that indicates a need to do things differently.
I digested this and then looked at my department's own processes for closing a project (which I mostly designed...). I realized we are pretty much guilty of not systematically looking for process improvements out of our documented lessons-learned. So here's what I am going to do about it:
1) Add a section to our SharePoint portal where all lessons-learned will be posted for department access. This way they are not buried in the close documents, but rather are on a searchable project management site.
2) Propose a quarterly review and write-up of trends and findings from this information and hopefully publish it to the department, better still all PMs in the company (informally).
3) See if we can facilitate this partly through a quarterly project management retreat where we can concentrate on this stuff and really get into why certain things are happening and what the root causes are.
Focus on a different problem that one of my colleagues from another area shared with me: How to get project team members to offer honest feedback on project manager performance. This colleague is new to project management and hungry for feedback on ways to improve his own PM performance as well as the practices he and his department use to execute projects. His frustration comes when team members offer little or no feedback for improvement when he knows from the project's performance that there are many opportunities.
His post-project completion lessons-learned sessions are not yielding the feedback he needs and wants, so he's trying to figure out other ways to get this. Possible obstacles:
1) Team members uncomfortable offering feedback in public settings - perhaps offer anonymous surveys.
2) Sense that the culture is too deeply ingrained for any changes to take place - seek executive sponsorship to drive real process improvements tied to cost savings and time-to-market speed.
3) Inertia... "we've always done it this way"... comfort. This is hardest to overcome. He'll have to get people to see the value and want to change their PM practices.
He's passionate enough to keep after this even in the face of slow progress. It's worth doing, because it will help us get new products to market faster.
Thursday, December 11, 2008
Monday, November 10, 2008
Rescheduled - Me at NEW-PMI - March, 2009
Due to the big storm on December 9, NEW-PMI (thankfully!) canceled their chapter meeting and rescheduled me to present on March 10 in Green Bay.
So - If anyone happens to be in Wisconsin's Green Bay area, I will be presenting to the Northeast Wisconsin PMI chapter on March 10. The topic is effective time management for project managers in a multiple project environment. I helped found the NEW-PMI chapter back in 2002 when I lived in the area. It's a great, fast-growing chapter.
Hope to see you there!
So - If anyone happens to be in Wisconsin's Green Bay area, I will be presenting to the Northeast Wisconsin PMI chapter on March 10. The topic is effective time management for project managers in a multiple project environment. I helped found the NEW-PMI chapter back in 2002 when I lived in the area. It's a great, fast-growing chapter.
Hope to see you there!
Thursday, October 16, 2008
Cool PM Stuff I am up to...
Outside of the regular gig, my life as a PM educator and academic is very exciting, as follows:
In October, I am teaching a 2-day project management seminar for the State of Wisconsin's Enterprise Leadership Academy through University of Wisconsin - Madison.
In November, I'm scheduled to teach a 2-day project quality course at UW-Milwaukee.
I'm also reviewing and developing some courses for University of California - Irvine and am going to teach an online course for them next spring.
At UW-Platteville, I am teaching a course this fall in their MSPM program and am scheduled to teach two courses in Spring.
I am teaching Managing the Project Team in Lakeland College's MBA program this fall and will teach a project procurement course for them in the spring.
On the PMI front, I will be doing two SeminarsWorld dates in 2009. PMI also invited me to speak at the 2009 Asia-Pacific Global Conference in Kuala Lumpur. I am hoping to get a SeminarsWorld for this conference as well.
And, perhaps most cool, I just got word that I am one of the 2008 recipients of the PMI Dr. Harold Kerzner Scholarship, sponsored by International Institute for Learning. I plan to start my doctorate studies yet this year, most likely through the University of Management and Technology in Arlington, VA.
In October, I am teaching a 2-day project management seminar for the State of Wisconsin's Enterprise Leadership Academy through University of Wisconsin - Madison.
In November, I'm scheduled to teach a 2-day project quality course at UW-Milwaukee.
I'm also reviewing and developing some courses for University of California - Irvine and am going to teach an online course for them next spring.
At UW-Platteville, I am teaching a course this fall in their MSPM program and am scheduled to teach two courses in Spring.
I am teaching Managing the Project Team in Lakeland College's MBA program this fall and will teach a project procurement course for them in the spring.
On the PMI front, I will be doing two SeminarsWorld dates in 2009. PMI also invited me to speak at the 2009 Asia-Pacific Global Conference in Kuala Lumpur. I am hoping to get a SeminarsWorld for this conference as well.
And, perhaps most cool, I just got word that I am one of the 2008 recipients of the PMI Dr. Harold Kerzner Scholarship, sponsored by International Institute for Learning. I plan to start my doctorate studies yet this year, most likely through the University of Management and Technology in Arlington, VA.
Redefining project success - more on the value of the Triple Constraints
On the various PM web sites and blogs I follow, especially on gantthead.com, there are lots of PMs writing about redefining what project success means. I've seen some fancy multi-dimensional models offered for looking at defining and measuring project success. Nearly all of these are looking at the deliverables post-project rather than measurement of success during executing and controlling.
Here's my reaction to most of these:
Let's not get so bogged down in redefining post-project success parameters that we forget to manage live projects.
On time, on budget, within quality expectations, and all agreed-to scope delivered remain the critical measures of success during the project's lifecycle. Post-project measures, I offer, should not be as much of a concern to the project manager as are the live project measures. A hokey analogy: Whether or not the customers like the aircraft you just delivered is immaterial if you don't land the thing successfully.
Use your basic and proven measures to bring the project safely and successfully to completion. After delivery, the sponsor and stakeholders can subject the project to further measurement of whether it meets objectives and fulfills the business case that got it approved.
Here's my reaction to most of these:
Let's not get so bogged down in redefining post-project success parameters that we forget to manage live projects.
On time, on budget, within quality expectations, and all agreed-to scope delivered remain the critical measures of success during the project's lifecycle. Post-project measures, I offer, should not be as much of a concern to the project manager as are the live project measures. A hokey analogy: Whether or not the customers like the aircraft you just delivered is immaterial if you don't land the thing successfully.
Use your basic and proven measures to bring the project safely and successfully to completion. After delivery, the sponsor and stakeholders can subject the project to further measurement of whether it meets objectives and fulfills the business case that got it approved.
Wednesday, October 8, 2008
The Holy Grail of Project Management Process and Methodology
I recently did some consulting for a high-tech division of a very large company (I'm under NDA, so that's as much description as I can give). The focus was on providing a base level of project management training while getting an idea of the unique project management challanges they face.
During a roundtable discussion during lunch, I was able to hear from the division's VP, key operations exces and managers, and product development staff, marketing staff and engineers. While the issues were framed in the context of their specific environment, the essential problems are ones I (and probably you) have observed and experienced throughout my project management practice and teaching career.
The senior managers responsible for delivering projects want project management processes applied to ensure successful project delivery and to provide accurate status reporting on projects. Those managing the projects really want to do this for themselves as well as for their bosses.
Senior executives want this information and want their organization to efficiently deliver projects.
But... No one wants to do any extra work to develop and execute on project management process... because, see, we have all these projects. And, the operations/production people, while seeing the value of project management, also see themselves as tough, pragmatic managers who choose not to add project management "overhead" to their jobs of getting products manufactured and process improvements in place. You know, getting real work done.
What's a project management advocate to do? If everyone acknowlwedges the need and value of project management to helping the organization deliver projects more efficiently, but everyone is too busy to execute project management, how do you get out of this loop? How do you win over the operations types who feel that project management does not add value to cranking out widgets?
The Holy Grail: Figuring out how to bring the most impactful, valuable components of project management to the organization while focusing on suppressing work perceived as overhead to make it happen. Some of the high-value examples are so simple, basic, yet meet with resistance.
My favorite is the tracking of actual versus estimated hours used on project tasks by human resources. There is no more important metric to track than resource actuals. The additional metrics and reporting this step enables both tactically and strategically are legion, yet this basic project management function meets with tremendous resistance, even in some organizations that are doing many other standardized and robust PM practices. Why?
This step is, depending on the organization:
Perceived as extra work, considered too detailed or granular, labeled as "big brother is watching", and more...
In one project management class I was teaching a few years back, a participant said something along the lines of not being able to ask "professional people" to account for their time. I collapsed with disbelief and laughter. My first question was "you are paying these people, right?" Seriously, in this day and age no one collecting a paycheck should be questioning efforts to understand how their time is spent, especially in the context of getting better at projects.
This is just one example of many components of project management that could provide incredible value to organizations but meet with resistance because of perceived difficulty to implement or perception of overhead. Champions of project management must find that elusive Holy Grail - that balance of value versus detail and process.
With tracking actual resource hours, the project management advocate must: (1) find a cheap and easy tool to use (2) figure out the largest increment of time to track that will still add value to the project management process (3) sell this as a way to track projects and help build the organization's database of estimating resources, and certainly not an effort to see how people spend their time.
Another great example is the project charter. This is one of the most important documents in all of project management practice. Yet, it is surprising how many projects get launched in organizations of all types and sizes without a single, simple document that captures who launched the project, why it was launched and what it is supposed to achieve. The project charter is another low effort, high-value step in adopting basic project management practices.
Simply documenting why a project was launched, who is responsilbe for paying for it, managing it, and tracking how much time has been spent on it are low effort, high-value project management tools that will pay dividends fast. The important thing with the charter is to keep it brief and simple. 2 - 3 pages is enough detail to document what is supposed to be delivered, how, when, by whom, etc, but not so much that anyone can claim that it is too much overhead to write it.
Are these two examples the Holy Grail of project management? No... but you can make a strong business case against anyone who thinks it is overhead that doesn't add value by showing how little effort it could take to put these couple of basic items in place. That's the Holy Grail - high-impact, low-overheard project management process improvements that help the organization, improve the perception of project management, and, in the words of John Belushi in Animal House, "don't cost nuthin."
During a roundtable discussion during lunch, I was able to hear from the division's VP, key operations exces and managers, and product development staff, marketing staff and engineers. While the issues were framed in the context of their specific environment, the essential problems are ones I (and probably you) have observed and experienced throughout my project management practice and teaching career.
The senior managers responsible for delivering projects want project management processes applied to ensure successful project delivery and to provide accurate status reporting on projects. Those managing the projects really want to do this for themselves as well as for their bosses.
Senior executives want this information and want their organization to efficiently deliver projects.
But... No one wants to do any extra work to develop and execute on project management process... because, see, we have all these projects. And, the operations/production people, while seeing the value of project management, also see themselves as tough, pragmatic managers who choose not to add project management "overhead" to their jobs of getting products manufactured and process improvements in place. You know, getting real work done.
What's a project management advocate to do? If everyone acknowlwedges the need and value of project management to helping the organization deliver projects more efficiently, but everyone is too busy to execute project management, how do you get out of this loop? How do you win over the operations types who feel that project management does not add value to cranking out widgets?
The Holy Grail: Figuring out how to bring the most impactful, valuable components of project management to the organization while focusing on suppressing work perceived as overhead to make it happen. Some of the high-value examples are so simple, basic, yet meet with resistance.
My favorite is the tracking of actual versus estimated hours used on project tasks by human resources. There is no more important metric to track than resource actuals. The additional metrics and reporting this step enables both tactically and strategically are legion, yet this basic project management function meets with tremendous resistance, even in some organizations that are doing many other standardized and robust PM practices. Why?
This step is, depending on the organization:
Perceived as extra work, considered too detailed or granular, labeled as "big brother is watching", and more...
In one project management class I was teaching a few years back, a participant said something along the lines of not being able to ask "professional people" to account for their time. I collapsed with disbelief and laughter. My first question was "you are paying these people, right?" Seriously, in this day and age no one collecting a paycheck should be questioning efforts to understand how their time is spent, especially in the context of getting better at projects.
This is just one example of many components of project management that could provide incredible value to organizations but meet with resistance because of perceived difficulty to implement or perception of overhead. Champions of project management must find that elusive Holy Grail - that balance of value versus detail and process.
With tracking actual resource hours, the project management advocate must: (1) find a cheap and easy tool to use (2) figure out the largest increment of time to track that will still add value to the project management process (3) sell this as a way to track projects and help build the organization's database of estimating resources, and certainly not an effort to see how people spend their time.
Another great example is the project charter. This is one of the most important documents in all of project management practice. Yet, it is surprising how many projects get launched in organizations of all types and sizes without a single, simple document that captures who launched the project, why it was launched and what it is supposed to achieve. The project charter is another low effort, high-value step in adopting basic project management practices.
Simply documenting why a project was launched, who is responsilbe for paying for it, managing it, and tracking how much time has been spent on it are low effort, high-value project management tools that will pay dividends fast. The important thing with the charter is to keep it brief and simple. 2 - 3 pages is enough detail to document what is supposed to be delivered, how, when, by whom, etc, but not so much that anyone can claim that it is too much overhead to write it.
Are these two examples the Holy Grail of project management? No... but you can make a strong business case against anyone who thinks it is overhead that doesn't add value by showing how little effort it could take to put these couple of basic items in place. That's the Holy Grail - high-impact, low-overheard project management process improvements that help the organization, improve the perception of project management, and, in the words of John Belushi in Animal House, "don't cost nuthin."
Friday, August 1, 2008
Doing the Right Thing, What's Happening August - December
Doing the Right Thing: In teaching my UW-Platteville course for their master's degree in project management program this summer, I've had the opportunity to review the project journals of over 20 students, all telling stories about live or recently-completed projects on which they were either the PM or a team member.
My observation from this work is almost certainly not original, but is still striking to me anyway: In project management, general business, and indeed, life, I think nearly everyone can quickly determine the Right Thing to do in a specific situation. Where we usually get hung up is with all the personal, psychological, organizational and environmental obstacles to actually doing it.
As we all know, so much of project management is communications. A colleague of mine often refers to The Conversations - those often-difficult conversations that one must have with sponsors, stakeholders, team members, vendors, etc. in order to do the Right Thing within the context of a project. Actually having those Conversations is far harder than one might think for many project managers. Concerns about job security, being liked, respected, reporting structure, and other factors influence whether and how the conversation occurs.
So, perhaps more project management training needs to focus on how to actually do the Right Thing - how to have the conversations, how to do an honest self-assessment prior to going into a potentially difficult situation, how to debrief one's self after a difficult situation, and how to get better at handling these. As PMs improve their tactical ability to actually do the Right Thing, we'll see more projects get completed within traditional and non-traditional definitions of success.
I am looking at a busy August - December outside of my day job: I am doing a couple of days of consulting for a firm in mid-August, presenting at a conference in September, teaching for UW-Madison in October, UW-Milwaukee in November, and teaching a semester-long course for UW-Platteville this fall semester. I am also scheduled to present at a couple of PMI SeminarsWorld in 2009, and have papers submitted for the Asia-Pacific Global Conference in Kualu Lumpur in February. Stay tuned...
My observation from this work is almost certainly not original, but is still striking to me anyway: In project management, general business, and indeed, life, I think nearly everyone can quickly determine the Right Thing to do in a specific situation. Where we usually get hung up is with all the personal, psychological, organizational and environmental obstacles to actually doing it.
As we all know, so much of project management is communications. A colleague of mine often refers to The Conversations - those often-difficult conversations that one must have with sponsors, stakeholders, team members, vendors, etc. in order to do the Right Thing within the context of a project. Actually having those Conversations is far harder than one might think for many project managers. Concerns about job security, being liked, respected, reporting structure, and other factors influence whether and how the conversation occurs.
So, perhaps more project management training needs to focus on how to actually do the Right Thing - how to have the conversations, how to do an honest self-assessment prior to going into a potentially difficult situation, how to debrief one's self after a difficult situation, and how to get better at handling these. As PMs improve their tactical ability to actually do the Right Thing, we'll see more projects get completed within traditional and non-traditional definitions of success.
I am looking at a busy August - December outside of my day job: I am doing a couple of days of consulting for a firm in mid-August, presenting at a conference in September, teaching for UW-Madison in October, UW-Milwaukee in November, and teaching a semester-long course for UW-Platteville this fall semester. I am also scheduled to present at a couple of PMI SeminarsWorld in 2009, and have papers submitted for the Asia-Pacific Global Conference in Kualu Lumpur in February. Stay tuned...
Wednesday, June 25, 2008
Triple Constraints Under Attack!
There's been some discourse recently on project management sites about whether the venerable Triple Constraints are still valid measures for determining project success. Here's a few thoughts:
First, they are not measures for success as much as they are parameters for project planning, scheduling and control. There is still plenty of value in using this model as a way of communicating to project sponsors and stakeholders that the constraints influence project decisionmaking and tradeoffs.
The Triple Constraints do not influence the quality or validity of the project's business case. Nor due they on their own take into account the fact that a project can be late and overbudget and still be perceived as wildly successful.
The triple constraints are just tools. They are valid in helping the PM and sponsor shape basic planning, scheduling and control issues and problems. However, these are not true measures of project success. A project can deliver on all three as well as agreed-to scope (which, by the way, is represented by the size of the triangle - don't tell me otherwise, I will argue with anyone on this forever!), and still be a failure if the business case was not valid or changed mid-project, or if the end users are unable to use the perfectly-executed project deliverables.
New ways of assessing a project add dimension to the evaluation and planning processes. They also, however, raise the debate of the role of the project manager. I do not completely agree with the ongoing movement that posits that PMs should be justifying their projects, making their business cases, etc. That's the sponsor's job - the PM helps. This is where the additional dimensions of project success and evaluation can help all involved to do their jobs more effectively.
First, they are not measures for success as much as they are parameters for project planning, scheduling and control. There is still plenty of value in using this model as a way of communicating to project sponsors and stakeholders that the constraints influence project decisionmaking and tradeoffs.
The Triple Constraints do not influence the quality or validity of the project's business case. Nor due they on their own take into account the fact that a project can be late and overbudget and still be perceived as wildly successful.
The triple constraints are just tools. They are valid in helping the PM and sponsor shape basic planning, scheduling and control issues and problems. However, these are not true measures of project success. A project can deliver on all three as well as agreed-to scope (which, by the way, is represented by the size of the triangle - don't tell me otherwise, I will argue with anyone on this forever!), and still be a failure if the business case was not valid or changed mid-project, or if the end users are unable to use the perfectly-executed project deliverables.
New ways of assessing a project add dimension to the evaluation and planning processes. They also, however, raise the debate of the role of the project manager. I do not completely agree with the ongoing movement that posits that PMs should be justifying their projects, making their business cases, etc. That's the sponsor's job - the PM helps. This is where the additional dimensions of project success and evaluation can help all involved to do their jobs more effectively.
Tuesday, May 13, 2008
Completed my master's degree
This is purely a celebratory post: This past Saturday I completed my master of science in project management at UW-Platteville and graduated from the program. It's great to be finished! I'll be teaching in this program over the summer and hope to maintain my association with this fine project management master's degree program for a long time.
Monday, April 28, 2008
Great Software firm, Madison PMI PDD and Teaching Updates
Smart PDF Converter Pro: I highly recommend this software and this company (SmartSoft). I was looking for software to convert a scanned PDF to an editable Word document. Long story short, I bought this software online - quick, seamless process. Turned out it did not do what I thought it did, which they quickly acknowledged, and they directed me to other software that would do what I needed - not theirs. Since I already have Adobe Acrobat Pro, I asked them for a refund, which they turned around in less than an hour.
High points - their software, although it did not meet my specific need, was great otherwise. Their tech support and customer service was great. They had no qualms pointing me to another source to get what I needed, and they issued a prompt refund, no questions asked. What a great firm! http://www.pdftodocconverterpro.com
Madison PMI PDD
So a couple of weeks ago, I attended and spoke at the Madison (WI) PMI Professional Development Day. It was held at Madison's Monona Terrace, which for those of you not familiar with Madison, is on the shore of Lake Monona and is a Frank Lloyd Wright-designed venue - neat place. They/we had some good keynotes, including the state's current CIO (Oskar Anderson) and the CEO of Tenrox, Rudolf Melik. Nice to see several old and newer colleagues including some folks who were at my talk at PMI-Milwaukee.
I also had the chance to be in Buck Joseph's morning session. Buck is an emeritus professor at UW-Madison, and for years taught the Persuasion and Influence Skills for Project Managers course in the UW-Madison Exec Ed Project Management certificate program. I was fortunate to have him as an instructor in the mid-90's in this capacity. Buck's style and reputation are well-known, and his presentation was standing room-only.
Now, had I known earlier that Buck was presenting at the same time as me in the afternoon, I would have been semi-depressed all day. Fortunately I did not realize this until after lunch. When I taught in the UW-Madison project management program's week-long, two- course sessions, I used to teach Managing Multiple Projects as the second course of the week and sometimes followed Buck. Talk about a hard act to follow. I received good evaluations, but one participant went as far as to say that no one should have to teach after Buck Joseph. He's that engaging and fun.
So, Buck's 3 PM session opposite mine was packed, and mine was a bit sparsely attended, as I suspected would be the case. At least with Buck's reputation, I can safely assume it was because so many people wanted to see Buck!
Teaching Updates
I am teaching a course in Project Quality Management for UW-Milwaukee on May 5 - 6. First time teaching this course for UW-M, and I am updating a fair amount of the material for this session.
UW-Platteville has asked me to teach in their M.S. in Project Management program this summer, and so I will be teaching a course called Interpersonal Skills for Virtual and Co-Located Teams. Since this is my first go at this in the UW-P program, Jeff Hathaway, another instructor, will be working with me. It is great to be graduating from UW-Platteville and then having the opportunity to get back into the program as an instructor.
High points - their software, although it did not meet my specific need, was great otherwise. Their tech support and customer service was great. They had no qualms pointing me to another source to get what I needed, and they issued a prompt refund, no questions asked. What a great firm! http://www.pdftodocconverterpro.com
Madison PMI PDD
So a couple of weeks ago, I attended and spoke at the Madison (WI) PMI Professional Development Day. It was held at Madison's Monona Terrace, which for those of you not familiar with Madison, is on the shore of Lake Monona and is a Frank Lloyd Wright-designed venue - neat place. They/we had some good keynotes, including the state's current CIO (Oskar Anderson) and the CEO of Tenrox, Rudolf Melik. Nice to see several old and newer colleagues including some folks who were at my talk at PMI-Milwaukee.
I also had the chance to be in Buck Joseph's morning session. Buck is an emeritus professor at UW-Madison, and for years taught the Persuasion and Influence Skills for Project Managers course in the UW-Madison Exec Ed Project Management certificate program. I was fortunate to have him as an instructor in the mid-90's in this capacity. Buck's style and reputation are well-known, and his presentation was standing room-only.
Now, had I known earlier that Buck was presenting at the same time as me in the afternoon, I would have been semi-depressed all day. Fortunately I did not realize this until after lunch. When I taught in the UW-Madison project management program's week-long, two- course sessions, I used to teach Managing Multiple Projects as the second course of the week and sometimes followed Buck. Talk about a hard act to follow. I received good evaluations, but one participant went as far as to say that no one should have to teach after Buck Joseph. He's that engaging and fun.
So, Buck's 3 PM session opposite mine was packed, and mine was a bit sparsely attended, as I suspected would be the case. At least with Buck's reputation, I can safely assume it was because so many people wanted to see Buck!
Teaching Updates
I am teaching a course in Project Quality Management for UW-Milwaukee on May 5 - 6. First time teaching this course for UW-M, and I am updating a fair amount of the material for this session.
UW-Platteville has asked me to teach in their M.S. in Project Management program this summer, and so I will be teaching a course called Interpersonal Skills for Virtual and Co-Located Teams. Since this is my first go at this in the UW-P program, Jeff Hathaway, another instructor, will be working with me. It is great to be graduating from UW-Platteville and then having the opportunity to get back into the program as an instructor.
Monday, April 7, 2008
Jim's response and other matters...
Jim Rapoza was kind enough to respond to my e-mail. He points out that for many people who need the kind of help with project management that good tool can provide, new processes introduced through these new tools can provide needed assistance.
In other news - initial feedback from PMI-Milwaukee last week was good. They had a nice crowd, and are at a new venue (Panos) since I last presented to this group. Next week is Madison PMI's Professional Development Day, where I am presenting "Losing Your Religion" again.
Gantthead is in the midst of a major push to expand their social networking capabilities. I am not a huge fan of this whole social networking deal, but within the context of a project management-specific site like Gantthead, it works for me.
In other news - initial feedback from PMI-Milwaukee last week was good. They had a nice crowd, and are at a new venue (Panos) since I last presented to this group. Next week is Madison PMI's Professional Development Day, where I am presenting "Losing Your Religion" again.
Gantthead is in the midst of a major push to expand their social networking capabilities. I am not a huge fan of this whole social networking deal, but within the context of a project management-specific site like Gantthead, it works for me.
Wednesday, March 26, 2008
March 3 issue of eWeek - Jim Rapoza's article on PM software
In the March 3 issue of eWeek, Jim Rapoza reviews some SAAS project management software, and states that "over the years, we've seem many interesting applications that have attempted to bring new methods and processes to project management..." There's more to his introductory generalizations, and I think Jim's point is that MS Project has been so dominant that not much innovation has been successful in the PM software arena.
The article prompted me to e-mail Jim, and to post here and elsewhere on one of my favorite soapboxes: Process before tools. As practitioner and academic in the PM field, I must again state to all that project management starts with development of good and repeatable process and then looks for the appropriate tools to automate and streamline a good process.
A good PM can excellently manage projects with a whiteboard and an abacus. Most PMs I know still consider Excel to be the ultimate PM tool. Many, many people make the mistake of thinking that because they have selected and implemented MS Project (or some other PM software) they are "doing project management."
My point - the article seems to infer that new PM software applications should drive change in the way projects are managed - not so. Good project management practices are independent of software. The software selected should support a PM specialization/practice area or organization's successful processes, not determine or drive them.
Jim's article talks about how one of the new programs (LiquidPlanner, which I really like the look of) addresses project management's general intolerance for uncertainty despite constant experience that the dates and estimates we PMs give with such confidence are in fact given with varying degrees of uncertainty. This is not by choice.
Project management does not generally tolerate uncertainty because the people paying for projects do not tolerate it. The key here is that there are process efforts in place, especially around software development planning, scheduling and control, that emphasize experiential estimating. These new tools seem to support this, but development of good process is still king.
Once project sponsors learn to accept some inherent uncertainty and PM processes evolve to manage and communicate this effectively, then the software can help support and streamline the management process. Software cannot and should not drive the way projects are managed.
The article prompted me to e-mail Jim, and to post here and elsewhere on one of my favorite soapboxes: Process before tools. As practitioner and academic in the PM field, I must again state to all that project management starts with development of good and repeatable process and then looks for the appropriate tools to automate and streamline a good process.
A good PM can excellently manage projects with a whiteboard and an abacus. Most PMs I know still consider Excel to be the ultimate PM tool. Many, many people make the mistake of thinking that because they have selected and implemented MS Project (or some other PM software) they are "doing project management."
My point - the article seems to infer that new PM software applications should drive change in the way projects are managed - not so. Good project management practices are independent of software. The software selected should support a PM specialization/practice area or organization's successful processes, not determine or drive them.
Jim's article talks about how one of the new programs (LiquidPlanner, which I really like the look of) addresses project management's general intolerance for uncertainty despite constant experience that the dates and estimates we PMs give with such confidence are in fact given with varying degrees of uncertainty. This is not by choice.
Project management does not generally tolerate uncertainty because the people paying for projects do not tolerate it. The key here is that there are process efforts in place, especially around software development planning, scheduling and control, that emphasize experiential estimating. These new tools seem to support this, but development of good process is still king.
Once project sponsors learn to accept some inherent uncertainty and PM processes evolve to manage and communicate this effectively, then the software can help support and streamline the management process. Software cannot and should not drive the way projects are managed.
Thursday, March 20, 2008
Upcoming Speaking Engagements
I'll be presenting "Losing Your Religion" at the Madison/South-Central Wisconsin PMI Chapter's Professional Development Day on April 18. My colleague David Antonioni will be presenting his Stakeholder Management Framework as well, so it will be a reprise of our presentations in Sydney.
I'll be presenting on "Improving Organizational Project Management" April 2 at PMI-Milwaukee. Very kind of PMI-Milwaukee to have me back - they are a great chapter with well-attended meetings.
If you are in the area, look forward to seeing you there.
I'll be presenting on "Improving Organizational Project Management" April 2 at PMI-Milwaukee. Very kind of PMI-Milwaukee to have me back - they are a great chapter with well-attended meetings.
If you are in the area, look forward to seeing you there.
Wednesday, March 12, 2008
My paper - PMI Asia-Pacific Global Conference
In case anyone is interested, I've posted the paper I presented at the PMI Global Conference in Sydney last week. Here's the link - it's on my website.
http://www.sdbworks.com/APGC_2008_paper.htm
I'll be delivering this same presentation in April at the Madison, WI PMI Chapter's Professional Development Day. I am currently working on paper and seminar proposals for PMI's 2009 GCs and SeminarsWorld. It would be great to get to another GC as a presenter, or as a seminar presenter.
http://www.sdbworks.com/APGC_2008_paper.htm
I'll be delivering this same presentation in April at the Madison, WI PMI Chapter's Professional Development Day. I am currently working on paper and seminar proposals for PMI's 2009 GCs and SeminarsWorld. It would be great to get to another GC as a presenter, or as a seminar presenter.
Wednesday, March 5, 2008
Day 3 - PMI Asia Pacific Global Conference
For me, the third and final day of the conference started with my own presentation, entitled "Losing Your Religion." This paper and presentation makes observations on the transformation of project manager to line or functional manager, and
considers the changes in attitude, management style and application of project management best practices that often occur when project managers move into line or functional management positions. Several of my new and old colleagues were in attendance, and the presentation went well, if I do say so myself (my colleagues said so, too, so I'll go with it).
I then attended a presentation by award-winning project manager Rohan J. David, PMP entitled "The Context of Project Management - Where Passion Lives." Rohan's presentation outlined several premises and approaches to project planning and execution. Most importantly, he pointed out that great projects entailed great risks, and therefore great passion for the outcome was a necessity for successful completion. Project managers must take that passion for excellence into their work in order to achieve success.
Rohan also outlined some scenarios to consider to ensure that projects were delivering on promises and also to improve on processes. Overall, an interesting presentation.
At lunch was time to connect with new friends and begin saying farewells to new friends, as Derek Walker and Paul Steinfort were headed home to Melbourne. PMI planned plenty of time over lunch and between sessions to ensure that networking opportunities were not cut too short by the need to break up developing conversations and relationships to scurry off to the sessions. This approach clearly worked well given the constant buzz of conversations and chances to meet and talk to project management practitioners and academics.
Both afternoon sessions I attended were focused on project portfolio management, which was my personal mandate for this conference. The first, presented by consultants Alex Brown and Jennifer Tharp, was called "Getting Your Projects Aligned to Strategic Goals." Overall, the presentation did not provide me a lot of new information, but the presentation style and interplay between Alex and Jennifer was great and well thought out. THey did provide a good framework for tracing and ensuring the alignment and confirming execution of strategic portfolios.
Continuing the trend I seemed to experience of "best for last", Michel Thiry and Rod Gozzard's presentation on "Successfully Implementing a Portfolio Management System in a Medium/Large Corporation" was excellent. It was so well-attended that they had to move to a bigger room. Using a case study approach and excellent interplay between them, Michel and Rod took us through a scenario in which an IT director was swamped with competing projects with limited resources and no functioning prioritization system.
Michel and Rod showed how their approach and plan led through a process that prioritized the projects based on their alignment with corporate strategy. Once this was complete, estimation of effort required to complete these projects enabled scheduling based on prioritization and available resources. Projects on the horizon enabled forecasting of resource demand and project throughput. One important point Michel and Rod made was that the foundation for this effort was good project and resource data, particularly resource time entry. This can be a sticking point for many organizations. I still do not understand why many companies and corporate cultures have issues with tracking people's time on project and non-project work for use in measuring project performance and capacity. It's not optional - it's an imperative.
The conference's closing session reminded us of the past 2.5 days and thanked the capable people from the Sydney area and PMI that made the conference happen. About 1000 people attended, making this the most well-attended Asia Pacific conference PMI has had to date. My conference is done - I'll be spending another day in Sydney to see more of the city and visit my company's Sydney office. Hopefully those of you following this have enjoyed reading.
considers the changes in attitude, management style and application of project management best practices that often occur when project managers move into line or functional management positions. Several of my new and old colleagues were in attendance, and the presentation went well, if I do say so myself (my colleagues said so, too, so I'll go with it).
I then attended a presentation by award-winning project manager Rohan J. David, PMP entitled "The Context of Project Management - Where Passion Lives." Rohan's presentation outlined several premises and approaches to project planning and execution. Most importantly, he pointed out that great projects entailed great risks, and therefore great passion for the outcome was a necessity for successful completion. Project managers must take that passion for excellence into their work in order to achieve success.
Rohan also outlined some scenarios to consider to ensure that projects were delivering on promises and also to improve on processes. Overall, an interesting presentation.
At lunch was time to connect with new friends and begin saying farewells to new friends, as Derek Walker and Paul Steinfort were headed home to Melbourne. PMI planned plenty of time over lunch and between sessions to ensure that networking opportunities were not cut too short by the need to break up developing conversations and relationships to scurry off to the sessions. This approach clearly worked well given the constant buzz of conversations and chances to meet and talk to project management practitioners and academics.
Both afternoon sessions I attended were focused on project portfolio management, which was my personal mandate for this conference. The first, presented by consultants Alex Brown and Jennifer Tharp, was called "Getting Your Projects Aligned to Strategic Goals." Overall, the presentation did not provide me a lot of new information, but the presentation style and interplay between Alex and Jennifer was great and well thought out. THey did provide a good framework for tracing and ensuring the alignment and confirming execution of strategic portfolios.
Continuing the trend I seemed to experience of "best for last", Michel Thiry and Rod Gozzard's presentation on "Successfully Implementing a Portfolio Management System in a Medium/Large Corporation" was excellent. It was so well-attended that they had to move to a bigger room. Using a case study approach and excellent interplay between them, Michel and Rod took us through a scenario in which an IT director was swamped with competing projects with limited resources and no functioning prioritization system.
Michel and Rod showed how their approach and plan led through a process that prioritized the projects based on their alignment with corporate strategy. Once this was complete, estimation of effort required to complete these projects enabled scheduling based on prioritization and available resources. Projects on the horizon enabled forecasting of resource demand and project throughput. One important point Michel and Rod made was that the foundation for this effort was good project and resource data, particularly resource time entry. This can be a sticking point for many organizations. I still do not understand why many companies and corporate cultures have issues with tracking people's time on project and non-project work for use in measuring project performance and capacity. It's not optional - it's an imperative.
The conference's closing session reminded us of the past 2.5 days and thanked the capable people from the Sydney area and PMI that made the conference happen. About 1000 people attended, making this the most well-attended Asia Pacific conference PMI has had to date. My conference is done - I'll be spending another day in Sydney to see more of the city and visit my company's Sydney office. Hopefully those of you following this have enjoyed reading.
PMI Asia Pacific Global Conference - Day 2
I spent the morning in two good sessions on project portfolio management. The first, delivered by Sandeep Marthur (currently of the Commercial Bank of Australia where he is deeply involved in project portfolio management), discussed the approach used there to manage portfolios and provided a case study in which addition of two strategic projects to a scheduled release of projects within the portfolio was evaluated within the context of that portfolio's goals and constraints.
Sandeep had some interesting points with regard to portfolio management discipline. One striking point was the concept that in most companies, the senior leadership up through the board of directors generally does not know if poor portfolio management strategies or poor project execution is the reason that many firms feel they do not receive the full expected value from their portfolios. His point was that senior leadership may very well focus their energies in the wrong areas, attempting to fix execution when in fact they are selecting poor projects, or worse have no strategy and process for managing the portfolio.
Sandeep spent some time on the PMI portfolio management process groups and also reminded me of the distinction between program management and portfolio management: Program management focuses on executing the projects right, where as portfolio management focuses on ensuring the right projects are being executed.
Sandeep was followed by Stephen Gorfein, a consultant in the field of project and portfolio management with a deep background in aerospace companies, having worked at one point for Howard Hughes. Stephen's discussion of portfolio management was more focused on the executive level processes that need to be in place to ensure effective portfolio management.
Interesting points from Stephen included the concept that portfolio management failures occur at the C-level and generally not due to actions or decisions below this level. Stephan also noted (as did Sandeep) the importance of having enterprise project management systems and data to feed the portfolio management process, noting that much of what is currently in the marketplace is too complex to be usable by many of those who need to develop and manage this type of data.
Following the extended lunch break, I sat through a rather poorly delivered and uninspired presentation on stakeholder management. It looked like the pain was going to end 30 minutes early as the presenter wrapped up, but then she ended with a controversial statement about being motivated solely by reward (versus recognition) at this stage of her career. So instead of getting loose a little early, many in the audience suddely felt compelled to bat this topic around for 20 minutes. Outcomes: Most people think that recognition is at least as important a motivator as reward.
The poor early session was more than offset by SoonKheng Koor's fantastic presentaion on Program Risk Management on Asian High-Profile Mega Project Success Stories. Presented by the Information Technology and Telecommunications Special Interest Group, SK's presetation was high-energy, very humorous, and full of excellent insight into risks that can occur in various areas in large multi-national, multi-cultural projects. He used case study examples from each of five huge airport projects he's worked on since the late 1990's, walking us through the development and resolutions of risk situations from each and how they could be avoided. He closed with insight on how the good program risk manager will never be noticed due to good risk management techniques while the crisis manager will be high-profile, rescuing projects from risks that could have been avoided through better risk management.
The Taste of Australia reception at the Museum of Contemporary Art got us all quickly out of learning mode and into networking and relaxation mode. Located near the Rocks area and with a spectacular view of Sydney Harbour, the Museum served as a great location for a great reception, with what looked like nearly all of the 1000+ attendees at the reception. Conversations with people from around the Asia Pacific region were interspersed by greetings from other Wisconsinites who had somehow found their way here. I followed this with dinner at one of the Rocks great restaurants with my old friends and colleagues Tony Munos and David Antonioni from Wisconsin and the UW System and new friends and colleagues Derek Walker and Paul Steinfort of Melbourne.
As I noted in yesterday's post, the energy level and opportunities for learning here are amazing. The most interesting conversations of my day were with a woman who has spent the last several years in Australia earning her master's degree in project management and then doing project management consulting, but is planning to return to her home in Indonesia to take over her family's businesses in marine logistics, shipbuilding and seaport construction.
The interesting thing here is how her decision to do this is in part motivated by the realization that all of the project management practices she's learned and applied over the last few years can be leveraged to projectize and streamline the various businesses and ventures of her family's company, leading to efficiencies and growth that might not otherwise be possible.
Sandeep had some interesting points with regard to portfolio management discipline. One striking point was the concept that in most companies, the senior leadership up through the board of directors generally does not know if poor portfolio management strategies or poor project execution is the reason that many firms feel they do not receive the full expected value from their portfolios. His point was that senior leadership may very well focus their energies in the wrong areas, attempting to fix execution when in fact they are selecting poor projects, or worse have no strategy and process for managing the portfolio.
Sandeep spent some time on the PMI portfolio management process groups and also reminded me of the distinction between program management and portfolio management: Program management focuses on executing the projects right, where as portfolio management focuses on ensuring the right projects are being executed.
Sandeep was followed by Stephen Gorfein, a consultant in the field of project and portfolio management with a deep background in aerospace companies, having worked at one point for Howard Hughes. Stephen's discussion of portfolio management was more focused on the executive level processes that need to be in place to ensure effective portfolio management.
Interesting points from Stephen included the concept that portfolio management failures occur at the C-level and generally not due to actions or decisions below this level. Stephan also noted (as did Sandeep) the importance of having enterprise project management systems and data to feed the portfolio management process, noting that much of what is currently in the marketplace is too complex to be usable by many of those who need to develop and manage this type of data.
Following the extended lunch break, I sat through a rather poorly delivered and uninspired presentation on stakeholder management. It looked like the pain was going to end 30 minutes early as the presenter wrapped up, but then she ended with a controversial statement about being motivated solely by reward (versus recognition) at this stage of her career. So instead of getting loose a little early, many in the audience suddely felt compelled to bat this topic around for 20 minutes. Outcomes: Most people think that recognition is at least as important a motivator as reward.
The poor early session was more than offset by SoonKheng Koor's fantastic presentaion on Program Risk Management on Asian High-Profile Mega Project Success Stories. Presented by the Information Technology and Telecommunications Special Interest Group, SK's presetation was high-energy, very humorous, and full of excellent insight into risks that can occur in various areas in large multi-national, multi-cultural projects. He used case study examples from each of five huge airport projects he's worked on since the late 1990's, walking us through the development and resolutions of risk situations from each and how they could be avoided. He closed with insight on how the good program risk manager will never be noticed due to good risk management techniques while the crisis manager will be high-profile, rescuing projects from risks that could have been avoided through better risk management.
The Taste of Australia reception at the Museum of Contemporary Art got us all quickly out of learning mode and into networking and relaxation mode. Located near the Rocks area and with a spectacular view of Sydney Harbour, the Museum served as a great location for a great reception, with what looked like nearly all of the 1000+ attendees at the reception. Conversations with people from around the Asia Pacific region were interspersed by greetings from other Wisconsinites who had somehow found their way here. I followed this with dinner at one of the Rocks great restaurants with my old friends and colleagues Tony Munos and David Antonioni from Wisconsin and the UW System and new friends and colleagues Derek Walker and Paul Steinfort of Melbourne.
As I noted in yesterday's post, the energy level and opportunities for learning here are amazing. The most interesting conversations of my day were with a woman who has spent the last several years in Australia earning her master's degree in project management and then doing project management consulting, but is planning to return to her home in Indonesia to take over her family's businesses in marine logistics, shipbuilding and seaport construction.
The interesting thing here is how her decision to do this is in part motivated by the realization that all of the project management practices she's learned and applied over the last few years can be leveraged to projectize and streamline the various businesses and ventures of her family's company, leading to efficiencies and growth that might not otherwise be possible.
Monday, March 3, 2008
Day 1 - PMI Asia Pacific Global Conference
Much of the morning of Day 1 was spent in registration, speaker orientation and further talks with new colleagues, but after lunch the conference went into session opened by a performance by aboriginal dancers in traditional dress and accompanied by the didgeridoo. By mid-day, jet lag was hitting me so hard I thought seriously of napping in public.
PMI CEO Greg Balestrero opened the proceedings by talking about the power of project management practices in diverse areas from the non-profit sector to BMW's complete re-engineering of engine designs. His point, made both in the speaker orientation session as well as the general opening session, was that project management practices continue to grow and be recognized as a key component of growth and success in all sectors public and private, profit and non-profit.
A thought-provoking statement from Greg: Looking around the room at the assembly of project managers at this conference, know that the ability to successfully deliver any project, anywhere in the world, and to solve any project management problem, is in the room.
The keynote speaker was Robyn Meredith, a senior editor for Forbes magaize and author of a book called The Elephant and the Dragon: The Rise of India and China and What it Means for All of Us. Robyn's talk was interesting, but did not cover any new ground.
In a nutshell: People in developed countries should all be worried about outsourcing both due to potential job loss as well as wage equalization in a global job market; China and India are different and not necessarily what we perceive; the rise of both countries has created a new middle class of consumers that are competing for goods and services and driving up prices; India's infrastructure is shoddy, China is polluted, and the major changes are causing big cultural changes in both countries.
Although the presentation was uninspired, the topic itself is interesting enough that I think I'll read the book.
The afternoon was devoted to focus sessions. The first one I attended was a little rocky, althought the topic was potentially interesting: Relationship Between Project Governance and Project Performance. As it turned out, the presenter is in the early stages of developing a PhD thesis, and so we were given a preview of where the research was headed rather than the outcomes that most in the audience were interested in.
The second session I attended was on the Intersection of Project Success and Leadership. It covered a lot of things most project managers are aware of, as presenter Bill Craddock noted at the outset. The presentation served as a great reminder of these elements and broke some new ground with regard to advancing research on the differing perceptions of project success based on one's role.
Bill Craddock points out that project manager's criteria for success is heavliy tied to the triple contraints, where stakeholders perception is tied to performance and value of the project deliverables. This is a key point in evaluating project coutcomes - I think most project managers recognize that a project can be called a success from the perspective of pure project management metrics, but be considered a failure in terms of delivering value or performance, and vice-versa.
Bill also discussed the varying perceptions and definitions of leadership, and provided the interesting statstic that the number of leadership books for sale on Amazaon.com stacked on top of each other would exceed the height of the imposing SYdney Harbour Bridge over 35 times.
The day ended with the welcoming networking reception - great food, great beverages, and more time to meet new people and greet old friends. My long-time friend and colleague David Antonioni, director of the Project Management Master's Certificate Program at the University of Wisconsin - Madison, was there. David is presenting his new framework for Stakeholder Relationship Management. Other presenters from the U.S. introduced themselves, and it was interesting to share stories on how we all came to attend this particular conference and rejoice in escaping the cold, snow and icy weather many of us in the U.S. Midwest and Northeast have endured this winter.
The atmosphere here is exciting. The project management community in Australia and the Asia-Pacific region is strong and has their own standards and concepts that in many areas go deeper and are more practical than PMI's. The wealth of advanced and terminal degree opportunities from Australian universities also speaks to the way in which project management is considered a vital part of successful business management as well as a key component to higher education in areas such as construction, design, and business.
PMI CEO Greg Balestrero opened the proceedings by talking about the power of project management practices in diverse areas from the non-profit sector to BMW's complete re-engineering of engine designs. His point, made both in the speaker orientation session as well as the general opening session, was that project management practices continue to grow and be recognized as a key component of growth and success in all sectors public and private, profit and non-profit.
A thought-provoking statement from Greg: Looking around the room at the assembly of project managers at this conference, know that the ability to successfully deliver any project, anywhere in the world, and to solve any project management problem, is in the room.
The keynote speaker was Robyn Meredith, a senior editor for Forbes magaize and author of a book called The Elephant and the Dragon: The Rise of India and China and What it Means for All of Us. Robyn's talk was interesting, but did not cover any new ground.
In a nutshell: People in developed countries should all be worried about outsourcing both due to potential job loss as well as wage equalization in a global job market; China and India are different and not necessarily what we perceive; the rise of both countries has created a new middle class of consumers that are competing for goods and services and driving up prices; India's infrastructure is shoddy, China is polluted, and the major changes are causing big cultural changes in both countries.
Although the presentation was uninspired, the topic itself is interesting enough that I think I'll read the book.
The afternoon was devoted to focus sessions. The first one I attended was a little rocky, althought the topic was potentially interesting: Relationship Between Project Governance and Project Performance. As it turned out, the presenter is in the early stages of developing a PhD thesis, and so we were given a preview of where the research was headed rather than the outcomes that most in the audience were interested in.
The second session I attended was on the Intersection of Project Success and Leadership. It covered a lot of things most project managers are aware of, as presenter Bill Craddock noted at the outset. The presentation served as a great reminder of these elements and broke some new ground with regard to advancing research on the differing perceptions of project success based on one's role.
Bill Craddock points out that project manager's criteria for success is heavliy tied to the triple contraints, where stakeholders perception is tied to performance and value of the project deliverables. This is a key point in evaluating project coutcomes - I think most project managers recognize that a project can be called a success from the perspective of pure project management metrics, but be considered a failure in terms of delivering value or performance, and vice-versa.
Bill also discussed the varying perceptions and definitions of leadership, and provided the interesting statstic that the number of leadership books for sale on Amazaon.com stacked on top of each other would exceed the height of the imposing SYdney Harbour Bridge over 35 times.
The day ended with the welcoming networking reception - great food, great beverages, and more time to meet new people and greet old friends. My long-time friend and colleague David Antonioni, director of the Project Management Master's Certificate Program at the University of Wisconsin - Madison, was there. David is presenting his new framework for Stakeholder Relationship Management. Other presenters from the U.S. introduced themselves, and it was interesting to share stories on how we all came to attend this particular conference and rejoice in escaping the cold, snow and icy weather many of us in the U.S. Midwest and Northeast have endured this winter.
The atmosphere here is exciting. The project management community in Australia and the Asia-Pacific region is strong and has their own standards and concepts that in many areas go deeper and are more practical than PMI's. The wealth of advanced and terminal degree opportunities from Australian universities also speaks to the way in which project management is considered a vital part of successful business management as well as a key component to higher education in areas such as construction, design, and business.
Sunday, March 2, 2008
Live from Sydney - Night 1
Greetings from Sydney, Australia. For a Wisconsin boy who doesn't get out of the country much, this is really, really cool.
I had the pleasure and good fortune to connect with some great people on my first night in Sydney. First was Tony Munos, who I've known for a few years since his days as director of UW-Platteville's Master's Degree in Project Management program and as a participant in one of my courses, is now an adjunct professor of project management at various universities worldwide including University of New South Wales and Univeristy of Wisconin - Platteville. Tony is dedicated educator who has taught project management worldwide.
We met up with Dr. Derek Walker, professor of project management and director of the Royal Melbourne Institute of Technology's project management doctoral program, and his wife Beverly (lecturer in human resource management at Victoria University of Technology specializing in emotional intelligence). Derek is co-author of an exciting new book called Procurement Systems - A Cross Industry Project Management Perspective and also is Journal Editor of the International Journal of Managing Projects in Business.
Derek's walkthrough of Procurement Systems - A Cross Industry Project Management Perspective was very intriguing. As project procurement management is a critical component of successful projects in all verticals, this book offers important insights into building value into project procurement planning and execution. It focuses on the role project managers play in the project procurement process and the importance of influencing and making decisions that deliver value to project stakeholders and the organization.
We were also joined by Derek's friend and colleague Paul Steinfort, PMP. Paul is the founder and Managing Director of PSA Project, a project managment consulting firm, and is the immediate past President and a Fellow of the AIPM (Australian Institute of Project Management)(Victorian Chapter). Paul is speaking at the conference about his recent experiences and observations on practice and application of project management in post-disaster scenarios, most notably post-tsunami Indonesia. Paul's presentation should be interesting, as he delves into the key differences between accepted best practices and actual applications of project management in situations where much of the structure often taken for granted is simply not available.
It was both a great pleasure and humbling experience to talk project management and other topics with this group of people who contribute so much to the project management profession from the practice and academic perspectives. Today (Monday here) is the first full day of the conference. In my next post I'll let you know how it goes.
I had the pleasure and good fortune to connect with some great people on my first night in Sydney. First was Tony Munos, who I've known for a few years since his days as director of UW-Platteville's Master's Degree in Project Management program and as a participant in one of my courses, is now an adjunct professor of project management at various universities worldwide including University of New South Wales and Univeristy of Wisconin - Platteville. Tony is dedicated educator who has taught project management worldwide.
We met up with Dr. Derek Walker, professor of project management and director of the Royal Melbourne Institute of Technology's project management doctoral program, and his wife Beverly (lecturer in human resource management at Victoria University of Technology specializing in emotional intelligence). Derek is co-author of an exciting new book called Procurement Systems - A Cross Industry Project Management Perspective and also is Journal Editor of the International Journal of Managing Projects in Business.
Derek's walkthrough of Procurement Systems - A Cross Industry Project Management Perspective was very intriguing. As project procurement management is a critical component of successful projects in all verticals, this book offers important insights into building value into project procurement planning and execution. It focuses on the role project managers play in the project procurement process and the importance of influencing and making decisions that deliver value to project stakeholders and the organization.
We were also joined by Derek's friend and colleague Paul Steinfort, PMP. Paul is the founder and Managing Director of PSA Project, a project managment consulting firm, and is the immediate past President and a Fellow of the AIPM (Australian Institute of Project Management)(Victorian Chapter). Paul is speaking at the conference about his recent experiences and observations on practice and application of project management in post-disaster scenarios, most notably post-tsunami Indonesia. Paul's presentation should be interesting, as he delves into the key differences between accepted best practices and actual applications of project management in situations where much of the structure often taken for granted is simply not available.
It was both a great pleasure and humbling experience to talk project management and other topics with this group of people who contribute so much to the project management profession from the practice and academic perspectives. Today (Monday here) is the first full day of the conference. In my next post I'll let you know how it goes.
Wednesday, February 20, 2008
Two notes of interest - the project is done, and Sydney is bekoning!
On February 16, we went live with the website project I have been working on for the last 2.5 years. The deployment was successful, and our post-deployment support and stabilization period has so far gone well.
On March 5, I will present at the PMI Asia Pacific Global Congress in Sydney, Australia. I'll post the paper and presentation slides here soon.
On March 5, I will present at the PMI Asia Pacific Global Congress in Sydney, Australia. I'll post the paper and presentation slides here soon.
Thursday, February 14, 2008
An Unpopular Position?
In recent posts on gantthead.com and in ongoing discussions with colleagues in the business of project management education, I've engaged in many discussions with a common theme: The idea that project managers should be taught how to develop, and (more to the point of this post) expect to be involved with the development of business cases, and know how and be involved with cost justification and financial analysis of projects. For a few years, I bought into this position. It had to do with my then-current job duties perhaps, as well as the fact that I was (and continue to) evolving my understanding of the role of the project manager. Plus, the concept of developing project managers as business leaders was and is compelling and seductive - PMs are business leaders and should be running their projects with business objectives in mind.
Recently, though, I've determined to say "no - not the case." Now, it's doubtless valuable for project managers to know as much as possible about financial management for a variety of reasons. The more a PM knows about the financial aspects of business and the projects one is leading, the better job one can do. A PM's understanding of the project's business case will help the PM more effectively manage the project and the budget. And, PMs interested in career advancement would do well to add financial management and accounting knowledge to their personal portfolio.
However, the role of the project manager is not business case development, project justification, portfolio analysis, or calculating payback periods. Note I said "project manager." If your role specifically involves portfolio management, program management, business unit or department management, then I am not talking to you. I'm talking about PMs who manage projects. It's not your/our job to do business case analysis and justification of projects. It is our job to develop and provide the information that is used to perform this work: Estimates, risk analysis, resource requirements, schedules, etc.
But business case development and project justification is the job of other business people. For example - In my particular company, I work in the IS department. We have a portfolio of potential projects that have been requested but not funded. They are in future budgets as placeholders but have not been formally approved. In our project management methodology, we have a process through which we will go all the way through Design before providing a final and definitive estimate to the sponsor.
At that point, the sponsor can make the final decision: He/She has costs, a schedule, a design - everything needed to decide whether to fund the project. Has the project manager done any financial work? Yes - estimating of costs. The PM has not, and will not, do any work related to justification of the project, ROI, rate of return, payback period, etc.
It is the responsibility of the sponsor to explain why the project is needed and how it will benefit the company. The sponsor uses various information, including information from initial, high-level project estimates developed by a project manager, to do this.
Now - as a PM, I have done this type of work. It's been delegated to me by my boss, because I know how, and so I do it, then collaborate with him to fine-tune its presentation. Then he presents it to the corporate leadership and the project gets approved... or not. Once the project is underway, I am not accountable for reviewing whether the project will still achieve its expected ROI or payback period. I am accountable for providing accurate metrics and budget reporting, on which decisions about the project may be made by others.
So - Do we advocate that project managers should be taught how to develop business cases, do financial analysis of projects, calculate NPV, payback periods, ROI, IRR, etc? Maybe. It depends on what your career goals are. You do not need to know this to be an effective project manager. You might need to know this to be an effective manager of project managers. You should probably know something about this to be a progam manager and you definitely need to know this if you are running a project-based consulting firm, a business unit, or want to do this in the future.
Project managers who want to be good project managers don't need to worry too much about this. Projects don't fail because the PM did not know how to calculate Net Present Value. Projects fail because sponsors demanded detailed and unchanging estimates too early in the lifecycle, because stakeholders withheld information, because eager vendors underestimated the project's scope and cost and then tried to weasel out of delivering.
So - work on communications. Practice negotiating and communicating with sponsors and stakeholders. Work on managing vendors and developing air-tight statements of project scope and deliverables. Leave the financial analysis to those who need to justify the projects - but learn it if your career plans require it.
Recently, though, I've determined to say "no - not the case." Now, it's doubtless valuable for project managers to know as much as possible about financial management for a variety of reasons. The more a PM knows about the financial aspects of business and the projects one is leading, the better job one can do. A PM's understanding of the project's business case will help the PM more effectively manage the project and the budget. And, PMs interested in career advancement would do well to add financial management and accounting knowledge to their personal portfolio.
However, the role of the project manager is not business case development, project justification, portfolio analysis, or calculating payback periods. Note I said "project manager." If your role specifically involves portfolio management, program management, business unit or department management, then I am not talking to you. I'm talking about PMs who manage projects. It's not your/our job to do business case analysis and justification of projects. It is our job to develop and provide the information that is used to perform this work: Estimates, risk analysis, resource requirements, schedules, etc.
But business case development and project justification is the job of other business people. For example - In my particular company, I work in the IS department. We have a portfolio of potential projects that have been requested but not funded. They are in future budgets as placeholders but have not been formally approved. In our project management methodology, we have a process through which we will go all the way through Design before providing a final and definitive estimate to the sponsor.
At that point, the sponsor can make the final decision: He/She has costs, a schedule, a design - everything needed to decide whether to fund the project. Has the project manager done any financial work? Yes - estimating of costs. The PM has not, and will not, do any work related to justification of the project, ROI, rate of return, payback period, etc.
It is the responsibility of the sponsor to explain why the project is needed and how it will benefit the company. The sponsor uses various information, including information from initial, high-level project estimates developed by a project manager, to do this.
Now - as a PM, I have done this type of work. It's been delegated to me by my boss, because I know how, and so I do it, then collaborate with him to fine-tune its presentation. Then he presents it to the corporate leadership and the project gets approved... or not. Once the project is underway, I am not accountable for reviewing whether the project will still achieve its expected ROI or payback period. I am accountable for providing accurate metrics and budget reporting, on which decisions about the project may be made by others.
So - Do we advocate that project managers should be taught how to develop business cases, do financial analysis of projects, calculate NPV, payback periods, ROI, IRR, etc? Maybe. It depends on what your career goals are. You do not need to know this to be an effective project manager. You might need to know this to be an effective manager of project managers. You should probably know something about this to be a progam manager and you definitely need to know this if you are running a project-based consulting firm, a business unit, or want to do this in the future.
Project managers who want to be good project managers don't need to worry too much about this. Projects don't fail because the PM did not know how to calculate Net Present Value. Projects fail because sponsors demanded detailed and unchanging estimates too early in the lifecycle, because stakeholders withheld information, because eager vendors underestimated the project's scope and cost and then tried to weasel out of delivering.
So - work on communications. Practice negotiating and communicating with sponsors and stakeholders. Work on managing vendors and developing air-tight statements of project scope and deliverables. Leave the financial analysis to those who need to justify the projects - but learn it if your career plans require it.
Sunday, January 27, 2008
Quick Thoughts on Recent Events
I am writing this morning on two recent and unrelated observations in my PM life (Maybe three, as I am writing this the morning after being the volunteer software guy at our kid's school's annual fundraising auction, chaired by my wife).
1) What good is project management without any mandate to use it in the business? I am posting a lot on Gantthead.com, and someone saw my writing there and contacted me offline to chat about her current project management situation. She left a big consulting firm with lots of mature and rigorous PM practices to join a very small firm with virtually none. Her frustration is that, although she is charged with implementing better project management practices, the company management is offering no support, and her boss basically won't let her talk to anyone without filtering it through him first.
What??? You hired an experienced project manager, want to have "better project management", but you are going to offer no support and let the PM's boss muzzle her?? The sad thing is that this is descriptive of too many companies of all sizes and verticals. I offered some tips on developing tools and practices, but I also counseled this person to consider whether the fight would be worth the effort and risk to her job it would take to make any meaningful progress. I'm not sure how she landed where she is, but I am afraid getting out is the best course of action for her.
2) Sometimes the only way a project will ever get done is for the boss to set a date and say "get it done." My boss did this last week on my huge never-ending project. It required a change of mandate and mindshift for the project team. The team had previously been of the understanding that we would test until we were sure that every single bug was caught. My boss had recognized all along that this was unrealistic. We finally conveyed to the team that it was time to finish: Fix the current bugs, test one more time, and, unless there are absolute showstoppers, release the new website.
The team embraced this idea, and with one more burst of energy dove in to the final three-week push. As I have observed many times, project teams driven by quality (not schedule), need someone else to set a date for them, or they will never be done enough to complete the project. This can't come from the PM - it has to come from the sponsor, who updates their definition of what quality is and lets the PM and team know they are confident in the quality of the deliverable as is and wants to be done.
3) Charity auctions can benefit from project management (duh). After observing one committee on the auction my wife co-chaired almost run away with the auction, it was obvious that clearly defined roles, scope definitions, schedules and other things that project managers do automatically would have helped this bash. It was a success, but the runaway committee caused a lot of pain for the co-chairs, and to a lesser extent me, as I tried to keep them corralled into using the software the way we needed it.
Maybe next year I'll convince someone to call the top job the Auction Project Manager. Although if I do that, I might end up promoted from software guy to Auction Project Manager...
1) What good is project management without any mandate to use it in the business? I am posting a lot on Gantthead.com, and someone saw my writing there and contacted me offline to chat about her current project management situation. She left a big consulting firm with lots of mature and rigorous PM practices to join a very small firm with virtually none. Her frustration is that, although she is charged with implementing better project management practices, the company management is offering no support, and her boss basically won't let her talk to anyone without filtering it through him first.
What??? You hired an experienced project manager, want to have "better project management", but you are going to offer no support and let the PM's boss muzzle her?? The sad thing is that this is descriptive of too many companies of all sizes and verticals. I offered some tips on developing tools and practices, but I also counseled this person to consider whether the fight would be worth the effort and risk to her job it would take to make any meaningful progress. I'm not sure how she landed where she is, but I am afraid getting out is the best course of action for her.
2) Sometimes the only way a project will ever get done is for the boss to set a date and say "get it done." My boss did this last week on my huge never-ending project. It required a change of mandate and mindshift for the project team. The team had previously been of the understanding that we would test until we were sure that every single bug was caught. My boss had recognized all along that this was unrealistic. We finally conveyed to the team that it was time to finish: Fix the current bugs, test one more time, and, unless there are absolute showstoppers, release the new website.
The team embraced this idea, and with one more burst of energy dove in to the final three-week push. As I have observed many times, project teams driven by quality (not schedule), need someone else to set a date for them, or they will never be done enough to complete the project. This can't come from the PM - it has to come from the sponsor, who updates their definition of what quality is and lets the PM and team know they are confident in the quality of the deliverable as is and wants to be done.
3) Charity auctions can benefit from project management (duh). After observing one committee on the auction my wife co-chaired almost run away with the auction, it was obvious that clearly defined roles, scope definitions, schedules and other things that project managers do automatically would have helped this bash. It was a success, but the runaway committee caused a lot of pain for the co-chairs, and to a lesser extent me, as I tried to keep them corralled into using the software the way we needed it.
Maybe next year I'll convince someone to call the top job the Auction Project Manager. Although if I do that, I might end up promoted from software guy to Auction Project Manager...
Sunday, January 13, 2008
Fear's influence on estimating and scheduling
I, like most people, don't like to piss off other people I work with, especially my boss and his boss. I estimate this is true of about 95% of the normal humans in any workplace. The other 5% fall into a category of people I sometimes admire - those people who do not care if they piss off co-workers, and the subcategory of those who actively try to do so.
But I digress - The tendency to not want to piss off one's boss and higher-ups has a well-documented effect on project estimating and scheduling. My project team and I are living with the consequences of such effect as I write this. A year ago, we took a project we had spent the previous year trying to get done with a recalcitrant vendor back in-house and relaunched it ourselves, with much enthusiasm. The technical lead, key team leads, and I all collaborated on the best estimates as we could possibly do at the time, knowing full well that there were many unknowns that we would encounter throughout the project.
I insisted that we would use our ongoing learning and refinement of estimates to present a worst case, best case, likely case scenario of completion dates. Initially, management was not comfortable with this approach and asked for more refined dates. I maintained that this was not possible nor responsible, and we would continue to stick to this model. This approach earned the respect and appreciation of the project team.
However, this approach did not change the fact that upper management still wanted to ensure the project was completed as soon as possible. Feeling this pressure and wanting to avoid presenting dates that would cause agitation is what led the team and me to make a crucial estimating, planning and scheduling mistake. We had divided the project up into feature sets. Each feature set contained functionality development and other work related to a particular area of functionality. One example would be "US B2C Website" to denote all functionality and related work necessary to develop and deliver that e-commerce experience.
The plan called for 4 - 8 weeks of work and testing on each feature set followed by a release and demo to the business owners. The plan also called for the business owners to review and test each feature set after the release, provide their feedback and alert us to bugs. The plan did not call for a dedicated testing and bug-fixing period by the project team after each feature set release, and this is where we compounded our mistake, out of the desire to avoid upsetting management with completion date extensions.
After each feature set release, the team met to review the processes we used, revisit the project risks, and plan the next feature set and update the overall project schedule. After the first couple of releases, the project team realized the need to have a dedicated period of project team testing and bug fixing prior to kicking off the next feature set. However, we also realized that this would add a couple of months to the project schedule - a schedule that was already beginning to lean towards the high-end, worst case estimate for a completion date. We feared going back to our sponsor with the news that the project would take far longer than what he and others we expecting.
So, we pushed on without adding the extra time after each release. Our first pass at user acceptance testing (UAT) went badly, and we ended the scheduled week of UAT after two and a half days. A few more weeks of bug fixing and testing positioned us to launch another round, but problems stabilizing our environments led us to call off that round, too.
We're now two and a half months past our worst-case release date and the team is still testing, finding and fixing bugs. We're so close to done, and the bugs found are progressively easier to fix, but it is time-consuming and tedious work for the team. Everyday, my boss, the sponsor, asks when we will be ready for UAT and to release the site.
The project team and I recognize that the hours of comprehensive testing we're doing now are a direct result of not doing the testing incrementally after each feature set release. But at the time, it seemed more necessary to avoid the negative reactions that we perceived would come from extending the schedule by two months than to face reality and add the time.
This is testament to the influence that fear of pissing off one's boss, management or sponsor can have even over highly experienced project managers and project team members. My scenario occurs in a fairly open and trusting environment, so this speaks volumes on how far business project environments in general have to go to ensure that project estimates and schedules are developed without the influence of fear.
But I digress - The tendency to not want to piss off one's boss and higher-ups has a well-documented effect on project estimating and scheduling. My project team and I are living with the consequences of such effect as I write this. A year ago, we took a project we had spent the previous year trying to get done with a recalcitrant vendor back in-house and relaunched it ourselves, with much enthusiasm. The technical lead, key team leads, and I all collaborated on the best estimates as we could possibly do at the time, knowing full well that there were many unknowns that we would encounter throughout the project.
I insisted that we would use our ongoing learning and refinement of estimates to present a worst case, best case, likely case scenario of completion dates. Initially, management was not comfortable with this approach and asked for more refined dates. I maintained that this was not possible nor responsible, and we would continue to stick to this model. This approach earned the respect and appreciation of the project team.
However, this approach did not change the fact that upper management still wanted to ensure the project was completed as soon as possible. Feeling this pressure and wanting to avoid presenting dates that would cause agitation is what led the team and me to make a crucial estimating, planning and scheduling mistake. We had divided the project up into feature sets. Each feature set contained functionality development and other work related to a particular area of functionality. One example would be "US B2C Website" to denote all functionality and related work necessary to develop and deliver that e-commerce experience.
The plan called for 4 - 8 weeks of work and testing on each feature set followed by a release and demo to the business owners. The plan also called for the business owners to review and test each feature set after the release, provide their feedback and alert us to bugs. The plan did not call for a dedicated testing and bug-fixing period by the project team after each feature set release, and this is where we compounded our mistake, out of the desire to avoid upsetting management with completion date extensions.
After each feature set release, the team met to review the processes we used, revisit the project risks, and plan the next feature set and update the overall project schedule. After the first couple of releases, the project team realized the need to have a dedicated period of project team testing and bug fixing prior to kicking off the next feature set. However, we also realized that this would add a couple of months to the project schedule - a schedule that was already beginning to lean towards the high-end, worst case estimate for a completion date. We feared going back to our sponsor with the news that the project would take far longer than what he and others we expecting.
So, we pushed on without adding the extra time after each release. Our first pass at user acceptance testing (UAT) went badly, and we ended the scheduled week of UAT after two and a half days. A few more weeks of bug fixing and testing positioned us to launch another round, but problems stabilizing our environments led us to call off that round, too.
We're now two and a half months past our worst-case release date and the team is still testing, finding and fixing bugs. We're so close to done, and the bugs found are progressively easier to fix, but it is time-consuming and tedious work for the team. Everyday, my boss, the sponsor, asks when we will be ready for UAT and to release the site.
The project team and I recognize that the hours of comprehensive testing we're doing now are a direct result of not doing the testing incrementally after each feature set release. But at the time, it seemed more necessary to avoid the negative reactions that we perceived would come from extending the schedule by two months than to face reality and add the time.
This is testament to the influence that fear of pissing off one's boss, management or sponsor can have even over highly experienced project managers and project team members. My scenario occurs in a fairly open and trusting environment, so this speaks volumes on how far business project environments in general have to go to ensure that project estimates and schedules are developed without the influence of fear.
Saturday, January 5, 2008
Certification Creep = Revenue Generation. That's All.
Over the last few years, there has been a disturbing trend emerging within project management and to some extent general business with regard to certifications and continued education. Let's call it certification creep.
I think it began when some of the top executive education-type project management programs in the US started offering "advanced masters" certificates in project management. Now, I am on the advisory board for one of these programs, and many of the classes being offered are solid. Hell, I teach one of them at another university. But the main reason for offering the additional certification is pure and simple: revenue. How do you get 'em back in the class room once they have the initial certificate or master's certificate from your project management training program?
The answer, for the executive education programs in project management, is to create another level of certification. Now, to PMPs or others needing to obtain PDUs to maintain their professional certifications, making the case for attending additional courses beyond the basics needed to get the initial certificate or master's certificate in project management is pretty easy. Personally, I don't think the possibility of getting an "advanced master's" out of attending some additional classes is what will trigger people to attend the courses. If they are good and add value to the practice of the project management profession (yes, it is a profession), they'll sell - no extra certificate needed.
I know for a fact that these "advanced master's" programs and courses are hard to fill. My own course in an advanced PM program is "Assessment and Recovery of Troubled Projects." While I don't think the particular university continuing education program that offers my course does a very good job of marketing, I would still expect project managers to beat the doors down to get into this course, since we all get involved with troubled projects at some point in our careers. The fact is, the course draws around 6 people each offering. I used to take this personally, but all of the advanced master's certificate courses I am aware of are struggling to fill seats, one to the extent that the director is ending the program.
Bottom line? The bottom line. The advanced certification means nothing to employers, means nothing on a resume, and is not bringing master's certificate holders back in to the classrooms.
Another example is PMI's addition of the PgMP credential. For years, project managers have attained PMP status and advanced their careers to the point of managing multiple projects, programs, and PMOs of various sizes and flavors, all without a special credential. Then PMI added the PgMP. Why? Lots of legitimate reasons, but one main reason is to get credential-hungry PMPs to spend money on study prep materials and courses and fees to take another exam. I need to look at this more closely, I admit, but my initial evaluation of the PgMP is "why?"
For myself, I am spending my time and money on a Master's Degree in Project Management. I believe that a master of science in the profession speaks for itself, and will benefit my career development over the long haul far more than an advanced certificate or new PMI credential. An advanced degree means more to an employer than an advanced certificate.
On another front, there is a fairly recent push to create a culture of certification around business analysts. I get the sense that these valuable people are trying to create the same degree of respect for their work that project managers have been developing and enjoying for the last 15 or 20 years. While specialized BA training is valuable, I don't see the point in creating another sub-group of certification for this specialization. What is also driving this is money. There's dough to be made in perpetuating the sense that BA's need to be not only specially trained (they do) but also certified (they don't). So - Now I have to add the brochures I get for for BA training and certification to the pile of brochures for advanced PM certification destined for the recycling bin.
I think it began when some of the top executive education-type project management programs in the US started offering "advanced masters" certificates in project management. Now, I am on the advisory board for one of these programs, and many of the classes being offered are solid. Hell, I teach one of them at another university. But the main reason for offering the additional certification is pure and simple: revenue. How do you get 'em back in the class room once they have the initial certificate or master's certificate from your project management training program?
The answer, for the executive education programs in project management, is to create another level of certification. Now, to PMPs or others needing to obtain PDUs to maintain their professional certifications, making the case for attending additional courses beyond the basics needed to get the initial certificate or master's certificate in project management is pretty easy. Personally, I don't think the possibility of getting an "advanced master's" out of attending some additional classes is what will trigger people to attend the courses. If they are good and add value to the practice of the project management profession (yes, it is a profession), they'll sell - no extra certificate needed.
I know for a fact that these "advanced master's" programs and courses are hard to fill. My own course in an advanced PM program is "Assessment and Recovery of Troubled Projects." While I don't think the particular university continuing education program that offers my course does a very good job of marketing, I would still expect project managers to beat the doors down to get into this course, since we all get involved with troubled projects at some point in our careers. The fact is, the course draws around 6 people each offering. I used to take this personally, but all of the advanced master's certificate courses I am aware of are struggling to fill seats, one to the extent that the director is ending the program.
Bottom line? The bottom line. The advanced certification means nothing to employers, means nothing on a resume, and is not bringing master's certificate holders back in to the classrooms.
Another example is PMI's addition of the PgMP credential. For years, project managers have attained PMP status and advanced their careers to the point of managing multiple projects, programs, and PMOs of various sizes and flavors, all without a special credential. Then PMI added the PgMP. Why? Lots of legitimate reasons, but one main reason is to get credential-hungry PMPs to spend money on study prep materials and courses and fees to take another exam. I need to look at this more closely, I admit, but my initial evaluation of the PgMP is "why?"
For myself, I am spending my time and money on a Master's Degree in Project Management. I believe that a master of science in the profession speaks for itself, and will benefit my career development over the long haul far more than an advanced certificate or new PMI credential. An advanced degree means more to an employer than an advanced certificate.
On another front, there is a fairly recent push to create a culture of certification around business analysts. I get the sense that these valuable people are trying to create the same degree of respect for their work that project managers have been developing and enjoying for the last 15 or 20 years. While specialized BA training is valuable, I don't see the point in creating another sub-group of certification for this specialization. What is also driving this is money. There's dough to be made in perpetuating the sense that BA's need to be not only specially trained (they do) but also certified (they don't). So - Now I have to add the brochures I get for for BA training and certification to the pile of brochures for advanced PM certification destined for the recycling bin.
Subscribe to:
Posts (Atom)