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.
Wednesday, February 20, 2008
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.
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.
Subscribe to:
Posts (Atom)