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.
Sunday, January 13, 2008
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.
Friday, December 28, 2007
Project Management and Politicians
About once every month, the papers in Wisconsin's state capital of Madison run an article on the latest scandal related to a state IT project that is over budget, late, mismanaged, and generally messed up. Over the last year or so, we've seen a driver's license software program get bad press because it functioned worse than the system it replaced, there have been scandals regarding e-mail systems and server consolidation projects at state agencies, a parting of ways with a consulting firm that was failing in developing a voter registration system (http://wistechnology.com/article.php?id=4414), an audit report identifying numerous projects that were behind and over budget, and now today's latest regarding a state Medicaid program that is exceeding its original budget and timeline (http://www.madison.com/wsj/home/local/index.php?ntid=264282&ntpid=3).
State politicians decry the mismanagement, announce investigations, agency directors resign and replacements are appointed with promises to do better, and the mess continues. One problem is that politicians and political appointees have no business overseeing projects, especially IT projects. It's one thing to build highways and bridges on time - these are known entities with plenty of supporting historical data on which to build good estimates for budgets and schedule (Boston's Big Dig, a project which was quietly closed recently, does not count. No one had ever attempted anything of that scale before. On the other hand, the Marquette Interchange project in downtown Milwaukee is fairing pretty well). IT projects, as I may have mentioned in this blog, are completely different animals.
When huge IT projects start to go awry, as they so often do, the political motivation is to cover up the problem rather than apply project management practices to it. Doubtless, on most if not all of these projects there is a state employee, a project manager, who knows what the right things to do are and wants to do them: Report status accurately, hold vendors and project team members accountable, and find ways to recover the project, or at least update plans and status based on what is really happening. But at each reporting level above them, there is someone whose cozy job is dependent on bad news not getting out for as long as possible.
Successful, professional project management is dependent on transparency and an absence of consequences for project managers who perform their function properly. It's not breaking new ground here to state that successful projects require an environment in which project managers and project teams are rewarded for honesty and collaboration, and held accountable for obscuring facts and real status, engaging in turf wars and empire-building and general failure to collaborate for the benefit of the project and its stakeholders.
A system in which political appointees and/or elected officials are responsible for overseeing project management of state IT projects is doomed to fail. Only an independent professional project management office could provide the processes, leadership and oversight needed to ensure that state IT projects are effectively, and more importantly, honestly managed. Wisconsin state IT projects are the subject of numerous "official" proposals for bringing better oversight to these projects. None of the proposals or ideas I have seen call for leadership and oversight by senior-level professional project managers.
I think this means that we will be reading about troubled Wisconsin IT projects for years to come.
State politicians decry the mismanagement, announce investigations, agency directors resign and replacements are appointed with promises to do better, and the mess continues. One problem is that politicians and political appointees have no business overseeing projects, especially IT projects. It's one thing to build highways and bridges on time - these are known entities with plenty of supporting historical data on which to build good estimates for budgets and schedule (Boston's Big Dig, a project which was quietly closed recently, does not count. No one had ever attempted anything of that scale before. On the other hand, the Marquette Interchange project in downtown Milwaukee is fairing pretty well). IT projects, as I may have mentioned in this blog, are completely different animals.
When huge IT projects start to go awry, as they so often do, the political motivation is to cover up the problem rather than apply project management practices to it. Doubtless, on most if not all of these projects there is a state employee, a project manager, who knows what the right things to do are and wants to do them: Report status accurately, hold vendors and project team members accountable, and find ways to recover the project, or at least update plans and status based on what is really happening. But at each reporting level above them, there is someone whose cozy job is dependent on bad news not getting out for as long as possible.
Successful, professional project management is dependent on transparency and an absence of consequences for project managers who perform their function properly. It's not breaking new ground here to state that successful projects require an environment in which project managers and project teams are rewarded for honesty and collaboration, and held accountable for obscuring facts and real status, engaging in turf wars and empire-building and general failure to collaborate for the benefit of the project and its stakeholders.
A system in which political appointees and/or elected officials are responsible for overseeing project management of state IT projects is doomed to fail. Only an independent professional project management office could provide the processes, leadership and oversight needed to ensure that state IT projects are effectively, and more importantly, honestly managed. Wisconsin state IT projects are the subject of numerous "official" proposals for bringing better oversight to these projects. None of the proposals or ideas I have seen call for leadership and oversight by senior-level professional project managers.
I think this means that we will be reading about troubled Wisconsin IT projects for years to come.
Friday, December 21, 2007
Why can't we hit dates?
My boss asked a few months back why it is so hard to hit dates with big software development projects. It's almost a rhetorical question, and I think at a high level he, and most managers, know many of the answers.
But - here goes: In software development we're asked to provide a completion date with most of the work still unknown. Only when a PM or a project team is estimating a project they have done several times, and have absolute certainty of the scope, can they provide an accurate estimate of effort and schedule. With software development, every project is an unknown. The only way to hit a date to is to set it and then accept whatever deliverables can be done by that date. This does not achieve the goal of meeting what stakeholders want by that date but rather achieves a purely date-driven goal.
Not to get on the Agile bandwagon too much, but the idea of getting the stakeholders to look at completed software at regular intervals and declare the project done enough when they have the functionality they want is a pretty good one. Gathering all requirements up front helps the planning process but by no means guarantees completely accurate effort estimates or duration estimates unless the work very closely mirrors other projects and holds no major risks.
My boss expressed a desire to create a model where, in many cases, he could "turn the resource knob" and offer faster completion at higher costs when necessary. There is a point at which you cannot add more resources and go faster. It is important to note that more and more research shows that offshoring does not mitigate this - offshoring or outsourcing will hit business requirements road blocks, quality issues, or eventually the same law of diminishing returns. This is not new or unique to my current employer- this is a global condition that IS managers and PMs beat their heads over consistently.
Different situation - When I left a job as head of a custom solutions project group, my team and I could estimate video production projects within 5%. Publications projects could be a little more variable, but were still pretty accurate. Software projects were complete unknowns. Even when there were some basic similarities in content or subject matter, the programming side was unpredictable. The point here is that I had a team that developed estimates for a variety of project types on a daily basis - estimates that, if these projects went forward, would impact the team's performance bonuses each quarter. And despite that incentive and expertise, software projects remained incredibly difficult to estimate accurately.
Having had the need to do a lot of reading and research on software project estimating, the best piece I have seen on this topic recently is Joel Spolsky's piece, which you can find here: http://www.joelonsoftware.com/items/2007/10/26.html
Read it - it's good stuff.
But - here goes: In software development we're asked to provide a completion date with most of the work still unknown. Only when a PM or a project team is estimating a project they have done several times, and have absolute certainty of the scope, can they provide an accurate estimate of effort and schedule. With software development, every project is an unknown. The only way to hit a date to is to set it and then accept whatever deliverables can be done by that date. This does not achieve the goal of meeting what stakeholders want by that date but rather achieves a purely date-driven goal.
Not to get on the Agile bandwagon too much, but the idea of getting the stakeholders to look at completed software at regular intervals and declare the project done enough when they have the functionality they want is a pretty good one. Gathering all requirements up front helps the planning process but by no means guarantees completely accurate effort estimates or duration estimates unless the work very closely mirrors other projects and holds no major risks.
My boss expressed a desire to create a model where, in many cases, he could "turn the resource knob" and offer faster completion at higher costs when necessary. There is a point at which you cannot add more resources and go faster. It is important to note that more and more research shows that offshoring does not mitigate this - offshoring or outsourcing will hit business requirements road blocks, quality issues, or eventually the same law of diminishing returns. This is not new or unique to my current employer- this is a global condition that IS managers and PMs beat their heads over consistently.
Different situation - When I left a job as head of a custom solutions project group, my team and I could estimate video production projects within 5%. Publications projects could be a little more variable, but were still pretty accurate. Software projects were complete unknowns. Even when there were some basic similarities in content or subject matter, the programming side was unpredictable. The point here is that I had a team that developed estimates for a variety of project types on a daily basis - estimates that, if these projects went forward, would impact the team's performance bonuses each quarter. And despite that incentive and expertise, software projects remained incredibly difficult to estimate accurately.
Having had the need to do a lot of reading and research on software project estimating, the best piece I have seen on this topic recently is Joel Spolsky's piece, which you can find here: http://www.joelonsoftware.com/items/2007/10/26.html
Read it - it's good stuff.
Tuesday, December 18, 2007
The new strategy is working...
Replacing optimism with realism seems to be working. I never thought I would feel good about canceling planned UAT sessions, but I do. I know we did not proceed with them for the right reasons - we're just not quite stable enough.
The realism-driven approach to completing the project is paying dividends for the team and me. As much as our Agile-influenced project approach for the last year was intended to keep everyone communicating and remove barriers to candid communication, it's become clear that team members felt pressure to agree that they could meet desired dates, even when their gut knew it was unlikely. Now, people are speaking more freely about where they are with testing and whether we are ready to bring the users back in to test.
Since our sponsor (my boss) is bought in to this as well, the overall pressure to push to do user testing has been replaced with the responsibility of not restarting testing prematurely. This is much easier to manage.
The realism-driven approach to completing the project is paying dividends for the team and me. As much as our Agile-influenced project approach for the last year was intended to keep everyone communicating and remove barriers to candid communication, it's become clear that team members felt pressure to agree that they could meet desired dates, even when their gut knew it was unlikely. Now, people are speaking more freely about where they are with testing and whether we are ready to bring the users back in to test.
Since our sponsor (my boss) is bought in to this as well, the overall pressure to push to do user testing has been replaced with the responsibility of not restarting testing prematurely. This is much easier to manage.
Thursday, December 6, 2007
Optimism is bad
It finally hit me - the lesson learned in 1998 that I should be taking into this project: Optimism is bad. It's bad in project managers and bad in developers.
I've been consistently too optimistic in scheduling and managing dates, and the team has been too optimistic in believing that all bugs will be resolved at the last minute to be ready for user testing. Great quotes from the daily scrums: "Two days is an eternity in developer time." And, "Are you seeing any reasons to think we won't be ready to test on Monday?" Optimism...
This is the same thing that happened to me in 1998 with the BellSouth interactive training software. I'd test the beta and have no problems, schedule testing in Atlanta with the sense that nothing would go wrong, and then encounter problems with varying test platforms, missing video drivers and hardware, equipment damaged on arrival, or some other thing. Once we got through the optimistic dates and hopes that we would be ready for scheduled training deadlines and instead assumed the worst, we got the project done, and everyone stayed employed to work another day.
So - we're adjusting our sights and approach to remove optimism and instead rely on the bug reports and test data to tell us when we are ready to bring our users back in. And, we are setting the expectation that we will need to do a few more rounds of this before we are ready to release. The date will slip into the new year, but everyone seems ready to accept that as the price of a quality project. Best of all, our sponsor and key stakeholder are in accord that this is the way to go.
I've been consistently too optimistic in scheduling and managing dates, and the team has been too optimistic in believing that all bugs will be resolved at the last minute to be ready for user testing. Great quotes from the daily scrums: "Two days is an eternity in developer time." And, "Are you seeing any reasons to think we won't be ready to test on Monday?" Optimism...
This is the same thing that happened to me in 1998 with the BellSouth interactive training software. I'd test the beta and have no problems, schedule testing in Atlanta with the sense that nothing would go wrong, and then encounter problems with varying test platforms, missing video drivers and hardware, equipment damaged on arrival, or some other thing. Once we got through the optimistic dates and hopes that we would be ready for scheduled training deadlines and instead assumed the worst, we got the project done, and everyone stayed employed to work another day.
So - we're adjusting our sights and approach to remove optimism and instead rely on the bug reports and test data to tell us when we are ready to bring our users back in. And, we are setting the expectation that we will need to do a few more rounds of this before we are ready to release. The date will slip into the new year, but everyone seems ready to accept that as the price of a quality project. Best of all, our sponsor and key stakeholder are in accord that this is the way to go.
Wednesday, December 5, 2007
Reliving a past project
I realized today that my current project is unfolding a lot like a software project I managed nearly ten years ago. In 1997 and 1998, I led an interactive multimedia training software for a client - BellSouth. As we got ready for usability testing, things started to go awry. We ended up firing a vendor that I know was doing the best they could, but had bit off more than they could handle. We had several testing misfires, missed due dates, heated discussions, and finally delivered the project several months late.
I was struck today by the similarities bewtween that project and my current project, although my current project is on a much larger scale. The thing I am struggling with now is "what lessons did I take away from the experience ten years ago that I could apply to this situation?"
I'm not coming up with easy answers. Much about how things are playing out is influenced by our corporate culture, which puts quality, cost management and work/life balance over due dates. But with our second attempt at user acceptance testing fizzling even though my team was confident just last week, there are emerging patterns that are not familiar to me, and I don't have a response in my past experiences to use, despite the similarities to a previous project.
In the next couple of days, I'll have to determine how to move the team forward while working through the team's functional manager. I'll let you know what how it goes.
I was struck today by the similarities bewtween that project and my current project, although my current project is on a much larger scale. The thing I am struggling with now is "what lessons did I take away from the experience ten years ago that I could apply to this situation?"
I'm not coming up with easy answers. Much about how things are playing out is influenced by our corporate culture, which puts quality, cost management and work/life balance over due dates. But with our second attempt at user acceptance testing fizzling even though my team was confident just last week, there are emerging patterns that are not familiar to me, and I don't have a response in my past experiences to use, despite the similarities to a previous project.
In the next couple of days, I'll have to determine how to move the team forward while working through the team's functional manager. I'll let you know what how it goes.
Subscribe to:
Posts (Atom)