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...
Sunday, January 27, 2008
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)