I haven’t written a text description of this process yet, sorry.
I’ve been really busy working on two upcoming things from Spark::red that I think you’ll all appreciate, so bear with me.
Project Process – ATG Development Practices
by
Tags:
Comments
5 responses to “Project Process – ATG Development Practices”
-
Interesting… Do I see ‘big requirements upfront’ there? What do you think about it?
Siarhei
-
Let’s call it moderately big requirements upfront.
I can tie 90% of all issues I’ve had with large ATG development projects to either poorly defined requirements, or accepting too many changes in the requirements without impacting them correctly.
I’ll address the four reasons for wastage mentioned in the link you referenced.
* The requirements change:
Yes, requirements will change. If you let that stop you from defining them to start then you’ll have no idea what the changes are, how they actually impact your workload and the project schedule. Also: try getting a client to pay you 2 million dollars without any defined requirements. Or try getting a team to commit to a budget and date without requirements. You can’t.* People’s understanding of the requirements change
Sure. The better documented you have them, the more people will all start on the same page, and the better change request process you have, the more people will stay on the same page. With a multi million dollar project both sides need to have a way to measure the success of the project and the contract.* People make up requirements
Yes. Yes they do. They have to in order to schedule and budget projects. I’m not really sure how to respond to this one. It’s just reality.* You effectively put a cap on what you will deliver
Yes, and more importantly you put a floor on what you will deliver. Again, budget, schedule, etc…. You need this minimum delivery scope. The linked site argues that you never deliver more, and that you just negotiate downward as you run out of time or resources. If you’re running out of time and resources, then there’s really no way you could have delivered more, is there?I think the purely agile approach they recommend is fine if your client is willing to be involved on a daily basis, and is okay paying you lots of money for unknown features at an unknown date. That seems highly unlikely to me. You can’t deliver an accurate cost/time estimate with the high level requirements they mention on the site. Accurate estimates are hard enough with low level requirements.
If anyone has had success with an ATG project for a client without defining requirements up front, I would love to hear about it, as the agile approach is very seductive.
-
Well I wont be agreeing or disagreeing with you on the points you’ve mentioned (as it will be a waste of time and effort). But I have to say that you mentioned few important points quite correctly, such as:
* Client commitment (and no one is saying on committing without *any* requirements, we are talking about defining comprehensive/big requirements upfront and for all iterations). If the client wants to have fixed price, fixed functionality and fixed schedule… well…
* Client (or client proxy) participation. As you mentioned quite correctly, the client or client-proxy needs to be involved closely (that’s one of the reasons why off-shore projects are more difficult to do in agile way).
I agree that agile approach might seem more seductive because it might seem you can dump the discipline (together with requirements) while it actually requires more discipline when done right (take scrum for example).
Actually the reason I asked this question (the original one :) is whether there are any specifics to working with ATG projects so that it has influence on how you do the project? Recently I got curious about ATG technology and there is little information on it, so your blog is probably one of the most comprehensive sources I found :)
-
I think the things that might make an average ATG project different from non-ATG dev projects, is that usually they are half a million dollars to three or four million dollar projects. Clients at that level usually demand fixed price (at that level of cost they can’t just have a running bill, their own budgets are limited and fixed), fixed schedule (usually coordinated with national marketing promotions or something time critical), and very often fixed functionality (you can’t spend 2 million dollars without knowing exactly what you’re getting). Obviously you have the tripod issue there, so ideally the implementer will provide the fixed timeline, based on the requirements. Once that timeline is fixed, being late is usually accompanied by breach of contract fines, or at least some burnt bridges.
Honestly many of these clients simply aren’t able to be involved on a daily basis. They’re a marketing VP at a Fortune 500 and need to kick a project off to meet a business need, and get it delivered in time for the Feb 10th product launch.
Take a new ATG e-commerce project. The requirements are going to be integration to back-end pricing, inventory, fulfillment, billing, etc… systems. E-commerce store front end with specific flows and merchandising requirements. And so on. You can’t not build one of those or the whole thing is going to be useless.
ATG is amazing technology, but given the costs of the software, and the scope of a typical implementation, it’s a whole different world from a general php/RoR/Seam project.
I don’t know if that helps any… :) If you have any specific questions, I’m happy to answer to the best of my ability.
-
Hi Devon: Thanks for providing the emphasis on why upfront requirements are important and why the customers enforce for fixed price. I am new to ATG and has been given a task for estimation. I am looking for some tips on what to look for (pitfalls) that need to be avoided and taken care during the estimation and planning. Any inputs would be of great help.
Leave a Reply