Steven Arnold <thoth.amon.i...@gmail.com> wrote .. > > On Nov 5, 2010, at 10:20 AM, lprefonta...@softaddicts.ca wrote: > > > Having expert people mastering several tools in any project increases the > > like > > hood of being on time and within budget. > > I agree partially. Given unlimited resources, it would be great for all the people > on the project to have a mastery of all the tools used in the project. But resources > are never unlimited, and therefore compromise is always necessary. I bet your > organization was a small, focused team of experts -- a sharp tool for specific > jobs -- not a large consulting organization with hundreds of employees and > dozens > of major projects.
That's why the large consulting organizations typically fail... I could give you around 2 billion$ worth of failed projects in the last 5 years driven by the big consulting firms here without having to dig very deep. I am not talking about the success of these big organizations (bill until the customer budgets are exhausted). I am talking about the success of the projects themselves. I can assure you than up here these large organizations are healthy. Not true about their customers budgets... but that's their business model. > > The primary point I was making was that each new technology introduces > overhead > in development, maintenance and operations. Therefore it should be included > only > if the benefit is compelling when compared to the change in costs associated > with > a team who can develop, maintain and operate a system that uses the > technology. Exactly what I have been saying earlier in this thread. Pick the proper tool... if a project was developed faster with it then guess what, the maintenance cost will be following the same trend. > If a team like yours introduces a new technology, eventually the customer will > have to maintain and operate it without your staff of top-notch experts to > hold > their hands. And I guess you guys weren't cheap in the first place. As they > say, > fast delivery, low cost, high quality -- pick any two. You were high quality > and > fast delivery. Yep but we were not either cheap or charging high fees. We used to sell fixed cost projects. Real fixed cost, not the "let's go in at cost + 3% and then lets make our bread and butter on change requests". And we were not trying to pull the customer out of is comfort bubble technology wise. However we were proposing original designs with the then trendy technologies that our customers embraced at the time. We knew more about their business and the software tool they used than their employees. That's what I call being a consultant, bringing some expertise and real solutions to the table, not just merely occupying a seat. > > As far as failed projects go, in my experience, most failed projects fail not because > the team is not good enough to deliver -- although this is possible -- but > because > of poor project leadership, poor executive support, requirements that shift > too > much, or disinterested or distant customers. These are essentially business reasons, > not technical reasons. These are valid reasons.. after the failure. The early detectable reason why projects are doomed to fail is that many projects are huge in scope and timeline and are not sliced to deliver some ROI fast enough. Customers are not getting usable components delivered in the near future. They just get vague promises that something will be delivered in x years. Nothing tangible there just vapor ware. And by the way can you pay me now since we completed 30% of the analysis... you can guess what is the ROI of such a delivery mile stone, it's worth about as much as toilet paper in terms of ROI. Given the pace of technology, user expectations, ... we should aim at short development cycles. Exactly the opposite of what occurs in these huge projects. We worked on projects worth more than 1 million dollars on several occasions but we never submitted proposals to bite the bullet at once. We focused on ROI milestones ... for the customer's sake. Luc > > steven > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first > post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
