My Projects Have Never Failed
-
Comments posted here are about the content posted at http://www.sqlservercentral.com/columnists/jchan/2892.asp
-
I once worked for a company where most of the programmers thought like you do. I left. It took a while but they finally went out of business. If the customer isn't satisfied, the project is a failure. Period. If you think doing your best is good enough, thing again. You may not have control over why the project failed, but it is still a failure. And if you want to keep getting paid, you better figure out how to make it a success.
-
Joe, it depends on how you see it.
I developed one system for the company which, according to the customers, was a failure.
The same system was also used for an automated process which has generated $10,000's monthly since it went live and performs tasks which the users say was impossible.
Would this be determined as a success or a failure?
Kindest Regards,David Rowland
-
A realy good motivational post and must read for the IT people of lower ranked who often faced this kind of situation. Most of the time if projects failed then failure imposed on them and in case of success, credit is given to the people who designed that project.
So I realy thankful to the author for writing such a motivational article.
-
It's funny
One day our department received a piece of paper from the vice president who said these were the specifications for a new application report.
The vice president said he thought the report should be done in a month.
Looks too much, but for VP it's OK
This was 1992 ...We used PL/SQL and Java(!!!) to build the web interface.
I understand now, why recruiters are asking for 15 year of Java experience
..took 12 of us (a project manager, a DBA, a business analyst, and nine developers) 2 years to finish the project.
Remember, we are still talking about 1(one) (uno!!!!) report. 24 person years!!!
P.S. I used to work with IT department of medium size university (20K students). We have developed in 2 person/month a system with similar functionality (sorry, no graphs).
Therefore, I consider the project above as a HUGE failure
-
Hi
Not a very convincing post. A project is successfull only when all the people associated with it feel its useful to them. The post talks about real situations that we face often.
If its felt that there are some issues with project then steps should be taken to correct them.
Ex:- As the author has said in the telecommunications project a meeting should have been organised between the consultants and users and any body else involved in the project to clear up things.
Regards
"Keep Trying"
-
Hi guys,
I am an manager-becoming-developer, and I think that the goal of a commercial project should never be the fun of the developer writing code. I feel it's very important that the developers in my team feel good about the work they are doing, that they think the technologies we're using are cool and that they have freedom to build "art" code. But this is not the goal of the project. The project wouldn't be here without the customer and his requirements which leads to customer's money. He, and only he can say if the project is a success or not. Just as he and only he can say if the software project works correctly or not. IT will always deliver to some kind of business, so what is the point delivering something the business won't use ?
I think the keys in all the described projects was understanding customer requirements and management decisions. Both of them poorly done. Sorry to say, but the way I see it - some of your projects failed. Don't worry, some of mine too
.Best regards,
Cristi
-
Any software development project - any project in fact - is a team process. The whole team owns it and the whole team succeeds or fails together. If there is inadequate information avaiable, then that is a problem for the team to solve. If a team member is not contributing adequately for any reason, then that is a problem for the team to solve. It's not anybody else's responsibility. The decision on whether it is a failure should be based on success criteria set out at inception and agreed with the ultimate users. In the real world, that often does not happen, but user satisfaction (including functionality, time and cost) has to be the only criterion.
The scenarios described suggest to me a horribly hierarchical organisation where each individual throws their bit over the wall to the next in the chain. 'Ive done my bit - the rest aint my responsibility'. Guaranteed recipe for failure according to any criteria!
-
I have to agree with Stewart. It is a very poor team that contains individuals with an attitude that isolates them from the success of the team as a whole.
Sadly IT tends to attract more introverted individuals who are just happy to sit in a corner and code. No problem with that at all (we need focused coders, of course) but when it comes to making a decision on whether a project has been a success there is so much more to it than in an individual perception. We are a service industry and if we are not providing a satisfactory service to our clients as a whole then we have all failed.
-
A project can fail even if the entire development team are well-motivated geniuses with all the resources they require. A single developer can certainly be extra-ordinarily succesful and yet participate in a project that will be deemed a failure.
When I was a young developer I soon came to realise that I couldn't let my view of my self-worth be determined by the end result of a process that I was just one small part of; I had to concentrate on doing my part of the job well, and helping my colleagues where I could.
I think the author should be very careful to distinguish between personally being successful and having a successful project. I believe the author is trying to remind us of that distinction and remind us developers that they can be proud of the work they have performed even if the project failed by any objective criteria.
But that's not quite the end of the story ...
As one is given more and more responsibility for the management of a project one becomes more and more responsible for the project's success. If one wants to take on that responsibility, they need to recognise a project failure when they see it and call it what it is. If you don't distinguish between successful projects and failed projects one can't lead their team to create more successes than failures.
As many others have posted, the success of the project is best determined by whether all parties involved (purchaser, end-users, purchaser's upper management, producers upper management, the developers, the producer's accounts department) left happy with the project.
-
Dear oh dear oh dear.... what a total cop out from the author. If the eventual users don't or can't use the system, it's a failure, no matter how good the program writing is.
If the eventual result is vastly different from that desired at the start of the exercise, it's a failure.
What we saw in the author's 'not me gov, I wasn't responsible- Ive done exactly what you asked me to do ' rant was the classic conflict of management and managing a project.
I write and administer for 80- 100 users across SQL, Crystal, MIS, and various other Microsoft programs. The golden rule is always - First define the objective: what are you trying to achieve, what's the end game, what do you want from this piece of project? Second: who is going to use it? How are they going to use it- what are they going to get out of it? Thirdly: will they use it? Will they get out of it what they need ( not what we want) to do their job?
When you start with those questions- not project management questions , but management questions - you buy into the responsibility you should be taking to ensure success. From the examples the author gave, it didn't appear that anyone had actually bought into their project - but just took the task and designed a process. That approach and the attitude that goes with it - is doomed forever- and no matter how clever at writing programs the author may be - a change of approach is advised else every project in the future will be a failure.
-
Yegh, what a lack of responsibility. As Stewart said, development is a team process - that includes your client. SPECIFICATIONS, Feedback meetings and demos are a good way to do this.
At my previous company, projects were heavily spec'd - User Requirements, Functional (both signed off by the client before coding starts officially), and post delivery As-Built. Yes they were a pain, but they made development life so much easier. Where I am now, there is no formal specification process, and I'm really missing them.
Feedback/Status meetings should be ~ weekly (with the client, no longer than 30min), and demos should be on development milestones (every few weeks). You don't necessarily need to promise particular items for the demos, but it's important for the client to see what the system is going to look like, and how it is going to behave. This allows the client to see where the development is heading and gives them plenty of time to correct course if needed.
-
I really have to disagree here (edit - I mean that I disagree with the article, not with the comments). People should always take responsibility for what they do. Doing exactly what "the boss" wants, even though you know it's wrong, has been the downfall of many companies.
Take the first example, the HMO. If you only found that the users disliked the idea when the project went into production, you clearly failed to do one of the basic tasks of any software project - talk wiith the end users to get their idea on the needs and requirements!! I'd say that the failure of this project should for the most part be blamed to IT.
The second example is not so clear-cut. Maybe the IT dept did a terrific job of explaining how costly this would be, but he was a typpical butt-headed manager who wanted it his way or the highway. Or maybe the IT department was not clear enough, making this one of the many projects in which the "just a bit more" mantra gets repeated over and over again. You can't expect to blame management for spending millions on a project if you constantly ask for just a bit more, suggesting that this will really be the last time....
It really bothers me to read articles like this, suggesting that you should not feel responsible for failed projects. If a project fails, you should reallly have a long and hard think about all the things you could have done differently. Just doing what you are told is not enough.
Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
Visit my SQL Server blog: https://sqlserverfast.com/blog/
SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/ -
I would agree with many of the comments. I learned a long time ago that often, if you give the users exactly what they ask for, it won't be what they want! Often our job involves communicating with the end users, understanding what their needs are and how they intend to use the product we will build, and restating back to them how we see things working if we build what they ask for. Often both sides will learn from each other and will, in turn, modify the original specifications.
If this communication does not happen, then there WAS a failure. Maybe not at the level of the coder who was simply told what to write, but certainly somewhere in the IT project management stream.
-
Ms. Wong. This article is truly amazing.
You give three different examples: "the users were very upset, they absolutely refused...", "my company was furious", "the company had a hard time selling the product," and you finish with "I can still say it is a successful project because I have done my best."
You say, "Success is in the eye of the beholder." Yes, and while you are the centre of your own universe, I guess all is well.
"How can I feel responsible for the failure of projects due to causes over which I have no control?" If you came to work for me, I'd expect you to participate actively in creating *business* success. Singing the c.y.a. song, you wouldn't last long.
The world is changing, as is the definition of success. Many workplaces I visit would find this attitude an obstacle to achieving true success: that is, where the customer gets something that pleases and delights them (which may not match what they asked for in initial requirements).
Are you contributing to communication that produces more value, at work? Or just fulfilling requirements? Here's an article on an evolutionary project approach that values communication and puts the customer first. If you are curious to see what work (even DBA work) looks like in some other organizations, have a look!
http://www.agilemodeling.com/essays/agileUsability.htm
Deborah Hartmann
Agile Community Editor
Viewing 15 posts - 1 through 15 (of 54 total)
You must be logged in to reply to this topic. Login to reply