On Sun, Feb 6, 2011 at 12:17 PM, Michael Grant <[email protected]> wrote: > This could easily be a topic unto itself. It's very important before you > begin a project to have a scope document. I call it a PDG (project > development guideline) but you can call it whatever. The most important role > of the PDG is to clearly define the scope and detail of the project. Leave > no stone unturned and then have the client sign off on it before you begin > any work. It can be tedious but it's benefits far, far outweigh the tedium.
That sounds suspiciously like Big Design Up Front which is a practice I abandoned a long time ago... A client never knows their entire set of requirements. It's unreasonable to think they do. I generally take a phased approach. I don't charge for the initial discovery meeting but out of that meeting I propose a phase to dig into the project requirements and produce a document outlining the basic constraints of the project - and I charge for that - followed by at least two phases to dig into design and implementation. But none of those are fixed cost. I simply don't do fixed cost projects (unless they're mind-numbingly simple). The design phase is intended to get the client some sort of site skeleton that they can click around in - and a document specifying a technical approach for implementation (frameworks, databases, overall architecture, selection of 3rd party integration / tools). Implementation is always T&M (per hour) and provides iterations that deliver incremental functionality. That way, the client is getting a continuous stream of value but they can also walk away at any milestone and decide to go with another vendor - armed with documentation and working code. > The beauty of the PDG is that it actually becomes easier to > get a client to pay for changes because they've already signed off on the > project scope. Then you create a Scope Change Request document when they > want changes. The iterative approach embraces change rather than 'punishing' the client for wanting change. Each iteration has an agreed set of functionality to be implementation and the client can, at any time, de-prioritize any item to swap in any higher-priority feature they've just thought up. Clients like this because they feel they can explore options and they aren't locked into some pre-agreed document that represents what (they thought) their business needed at some point in the past. Michael's approach is a very traditional waterfall style process and a lot of people like that. My approach is more in line with Agile methodologies which have become a lot more prevalent in recent years. -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:341911 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
