tag:blogger.com,1999:blog-15466608.post6019200893899443309..comments2008-08-09T03:25:53.756+10:00Craig Brownhttps://profiles.google.com/112202012347971122168noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-15466608.post-84226363827031456282008-08-09T03:25:00.000+10:002008-08-09T03:25:00.000+10:00<B>Problem #1:</B> Humans are flawed.<BR/><B>Problem #2:</B> Technology is flawed.<BR/><BR/>That's the reality, and it's better to accept it than to hope that you're project won't have to deal with it.<BR/><BR/>So from a scoping perspective, you'll always underscope. You can't capture every tiny tidbit of detail upfront, and even if you did - the people absorbing the requirements won't be able to fully absorb it all.<BR/><BR/>I think the key is executive sponsorship. There has to be someone overarching all of it, who can chop out the unnecessary fluff, mandate that users will use it, determine the critical go live pieces, etc...<BR/><BR/>For example, when we were building the Death Star - it was getting horrifically behind. I had to personally oversee it - I told them to cut out the cafeteria, do the ventilation later, and focus on the power systems and energy laser so that I could blow the planet Alderon in time.<BR/><BR/>Collaboration only gets you so far...Darth Sidioushttp://sithsigma.wordpress.comnoreply@blogger.comtag:blogger.com,1999:blog-15466608.post-72517304820777342552008-07-14T09:36:00.000+10:002008-07-14T09:36:00.000+10:00Yes Glen,<BR/><BR/>Defining what done looks like early is a really important task. Sure it changes as you travel, but it's a (the?) key defining milestone.Craig Brownhttp://www.blogger.com/profile/01210437173582289473noreply@blogger.comtag:blogger.com,1999:blog-15466608.post-37709821707663909312008-07-14T06:29:00.000+10:002008-07-14T06:29:00.000+10:00Add two deliverables near the end of the project<BR/>1. Transition to Business<BR/>2. Transition to Production<BR/>These two steps move the project from development and deployment into the production envirnment and then into the production environment with the business running the system.<BR/>There are many tasks and deliverables in these two phases that make that transition.Glen B. Allemanwww.niwotridge.comnoreply@blogger.comtag:blogger.com,1999:blog-15466608.post-19664848980118293482008-07-13T12:19:00.000+10:002008-07-13T12:19:00.000+10:00Yes.<BR/><BR/>Why do smart people like us end up in places like this?<BR/><BR/>:)Craig Brownhttp://www.blogger.com/profile/01210437173582289473noreply@blogger.comtag:blogger.com,1999:blog-15466608.post-37966755755728300472008-07-13T10:04:00.000+10:002008-07-13T10:04:00.000+10:00Hi Craig,<BR/><BR/>This exactly where I find myself at the moment with a large eHealth project I have just inherited. It started 10 years ago, and over seven million dollars has been spent on it, but more than half the end users refuse to use it! They have built from the ground up their own tool, which has its own set of problems, not the least of which is enterprise level backup!<BR/><BR/>I have suspended all work on the first project and funding for the 'ground up tool'. My intent is to kill both projects, work out how to backup and migrate data from both tools, and buy a commercial off the shelf product, possibly through a private public partnership.<BR/><BR/>More than half the problem can be attributed to inadequate and/or overly ambitious requirements. The next problem was poor user engagement and multiple delayed roll-outs. Then the product simply didn't keep up with technology - Moore's Law!<BR/><BR/>It's a good case study on how not to run a project - arghhh!!!!<BR/><BR/>Best Regards, GrahamGraham Durant-Lawhttp://www.durantlaw.info/noreply@blogger.com