Programming with
a dose of satire.
Programming
|
| ||||||||
 |
 |
|||||||
|
True Stories of Development Heaven |
||
|
Message Forum: Why Projects Succeed Have you been involved in projects that weren't canned, products that went to market, even projects that were under budget and on time? We know they've happened. If you were involved in such a project, we'd love to hear your story. What do you feel made the project a success? Agility? People? Architecture? Let us know! Alternatively, let us know your "war stories" of project failure...
Story Index:
The Stories: It just happened!!!Once a while,you may crash into a project which is destined to be success,atleast thats what happened to me, Still remember,those late night stays,skipping lunch and ofcourse a lot of fun things too-;)) Bug fixing,performance issue,and then to go to client side,and to be in the firing line. OK,what made it a success, I think apart from very good team work, the main thing which I think was different from some other projects,was great blending of our team with client's team.!!!! rohit rohit.dhall@eontec.com india, india Mon May 06 09:25:11 BST 2002 re: It just happened!!! Rohit -- I'm glad to hear the project went well! Working closely with another team makes it a double success. Out of interest, how many people were in your team? Did you follow any particular lifecycle (XP, RUP etc)? Matt Stephens London, England Mon May 06 11:53:22 BST 2002 Projects done on time, under budget We followed the old methodology of "Rquirement Gathering", "Proper Analysis & Design", "User Approval for the Designs", and "Proper Documentation". By the time we were ready to start coding, we knew exactly what we had to do. Although I have been a manager, and project manager for many years, I find that the biggest problem with most projects is too much "management involvement", when upper-management wants to get their hands into the project, that usually spells trouble.Why? because they, ususally, don't understand the technology, but still want to make technical decisions, or business decisions that impact the project negatively. That may be why Agile works for some companies, because Agile pretty much keeps management at bay, away from the development. I personally do not agree with Agile, as I believe that a system must be well documented, and technical documentation is very important for those who will ultimately inherit the system. I would say that 80% of our projects have been on time and under budget, and that is because, somehow, we have been able to seperate ourselves from micromanagement personalities. Manny Celi meceli@fedex.com Florida, USA Wed May 08 15:12:40 BST 2002 Just say no I've been involved in projects as team lead for approx 7 years. The difference is clarification in the beginning and the ability to just say no when the users ask for more stuff. To put it into perspective: it is very difficult to say no to those who are effectively your clients, so the only way round it is to say: There's too much to get it into the timeline. We realize all of these features are desirable for the company. We'd like you to choose those that are must have before the deadline and those that are not and stick to that. If the client refuses, the project manager must stick to his/her guns and say "well in that case we cant do it". Most times the clients are reasonable especially if you talk about "the other features could be in a version 2" Dan Browne zaphodxx@127.0.0.1 Ontario, Canada Tue Jun 11 14:31:21 BST 2002 Small teams yield quality software It's a well documented fact that most software projects get canned and never see the light of day. Of those that see the light of day, most of those never actually get used. There are a million reasons for this. Having spent many years down in the trenches, I see one common element: projects are overstaffed with average developers. A project team is much like a sports team. There are usually a couple of supremely talented players, followed by a few good players and lots of fillers to fill that empty office space. A software team has an optimal amount players for developing cohesive, coherent and consistent software. My experience has shown this to be about 5 or 6. Anything beyond this and the team starts to thrash: it spends more time talking rather than doing software. Oh, I've heard of successful projects where there are literally hundreds of designers and coders all working beautifully together but coordinating these mammoth teams is incredibly difficult. There are certainly cases where big teams are needed. My point relates to those average projects where a small team can deliver in 3 to 6 month window. The bottom line is this: a team staffed with 5 talented designers and coders will consistently outperform anything bigger staffed with average talent. Small, talented teams mean software is delivered faster, cheaper and of better quality. So why do project managers overstaff projects with the average people ? Good talent is in short supply. Plus, they simply can't stand the idea of having idle people not keeping busy. It looks bad. Better to keep everybody busy... besides, nobody will know what is the real cost of overstaffing. Nick Wed Jun 12 04:19:40 BST 2002 I agree Buy best, cry once. Bad programmers do negative work. Dino Thu Jun 13 11:36:40 BST 2002 Coad Series Book ?Better Software Faster? -- Free Chapter Download In this Coad Series book?s pivotal chapter ?The Continuous Step: Measure the Quality,? developers Haywood and Carmichael detail the secret to incorporating quality checks into your development process. Learn: -- How writing unit tests before changing code can make your process more effective, more satisfying, and make life easier. -- How project managers, architects, and developers can use built-in metrics to monitor progress. -- How to set reasonable testing limits and know when to release an application. -- How to use audits to check code compliance automatically?and free up your time for more important, and more creative matters. Download the chapter free now at www.togethersoft.com/bsf/310 KMcKnight moreinfo@togethersoft.com Wed Feb 26 22:20:40 GMT 2003 If the customer wants it to happen, it usually does We all bitch about clients and customers, but for all the successful projects I've worked on, much credit can be given to the customer. If a customer really wants the project to succeed, they'll pull out the stops and help you get there. They'll give you the business data you want, access to their people and they'll come to your meetings. These kinds of customers recognise that delivery is bi-directional - and it is. When the customer isn't depending on your success too much, that's when you can be in real trouble. I worked on a project recently where the client was always too busy to talk to us and wouldn't sign off anything because they were always out of the office. Our inexperienced account manager shouldn't've agreed to continue on this basis, but he was young, wanted the business and the comission etc. Sound familiar? There are many risks involved in project work and one of the biggest for me is that the customer isn't really that into this anyway or that they've been sold the system but really can't find a place for it in their business. Trouble with these kinds of risks is that no one wants to admit they're there as it's a bit like rejection; very hard to accept. I could go on and on about this, but like a previous poster said, sometimes you just get involved with something that's bound to succeed and I'll bet that most times it's got a lot to do with the customer. Best to all, NICK Nick Cresswell nickjcresswell@hotmail.com London, England Thu Jun 21 22:02:56 BST 2007 |
||
All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright © 1998-2005 Matt Stephens. ALL RIGHTS RESERVED.