@vesuvius: The documents have been thoroughly vetted and pored over by the folks doing the analysis. These haven't been static documents. We've also got approximately a dozen other projects going at the same time, so not all the time was on one project.
Under threat of it not getting done at all, the customer has been very engaged. The analysis team (lol, it was two people) knew that it would take a long time to complete the analysis because of other commitments, so at least once a month, they went to key stakeholders and refreshed the user stories and other findings, as well as validated any assumptions.
As far as change goes, that's been sticky a few times, but I think we've got the process hammered out. Like you indicate, the trick is to expect change. We're also trying out a more agile process with smaller sprints and regular deliverables, including cycles for UAT and minor adjustments, so that's helping with managing change and expectations.
That said, yes, you're concerns are very much on everyone's mind, and we're very cautious.
Yep. Most successful development teams I've seen treat development more like scientific research instead of a manufacturing process. When you think about it, software development is a bit like scientific research, almost everyone writing code is pushing boundaries of knowledge to some degree, otherwise there wouldn't be much point in writing that code.
@vesuvius: A few months ago we started a project where the project manager told the customer that he wasn't going to devote a single development hour to the project until the information gathering, business analysis, and other planning was all complete. This was something very new for our organization. After much wailing and gnashing of teeth the customer relented, and they did 4 months of business analysis, gathering specs and all of the stuff you wish you could do all the time. When the development package was handed off to the developers, we were in awe. It was a complete departure from previous projects. So far it's been quite fun. We never have to ask questions, it's all in the documents. Plus, it looks like we're beating our time estimates.
That's awesome.Can't even imagine project that runs with no change in specification at all. (Let alone those changes which requires throwing away fundamential assumption and introduce all the bugs hiding here and there in Business Logic Layer module that has no way to ever got fully covered by unit tests)
That's were schedules goes out of control.
And I don't want to blame PM for this. As in-house developers we don't have right to say "No" to changes as long as the users can show an actual business need there. Don't expect anyone above to side with you for resisting the change. They'll just say "if your application can't cover all business case, maybe they should just buy one of the "canned" software in the market and hire their expert to tweak it, and you have no use here".
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.