Click here to monitor SSC
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase ««12345»»»

My Projects Have Never Failed Expand / Collapse
Posted Monday, April 30, 2007 2:40 AM


Group: General Forum Members
Last Login: Monday, April 30, 2012 7:54 AM
Points: 18, Visits: 298

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.

Post #361889
Posted Monday, April 30, 2007 2:48 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Monday, June 16, 2014 3:57 AM
Points: 379, Visits: 55
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.
Post #361891
Posted Monday, April 30, 2007 2:57 AM



Group: General Forum Members
Last Login: Yesterday @ 9:30 AM
Points: 7,765, Visits: 11,375

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 MVP
Visit my SQL Server blog:
Post #361892
Posted Monday, April 30, 2007 4:20 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Sunday, November 6, 2016 5:52 PM
Points: 261, Visits: 470

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.  

Post #361905
Posted Monday, April 30, 2007 6:12 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, April 30, 2007 5:29 AM
Points: 1, Visits: 1
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!

Deborah Hartmann
Agile Community Editor
Post #361924
Posted Monday, April 30, 2007 6:38 AM

SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Wednesday, May 25, 2016 6:36 AM
Points: 4,030, Visits: 1,702


Calling project #1 a success because it met the specification?  Yet the last line clearly stated that it failed because no one ever used it!

There is no way that you can justify calling an unused project a success just because it met the spec.




Post #361937
Posted Monday, April 30, 2007 7:04 AM


Group: General Forum Members
Last Login: Wednesday, November 16, 2016 6:51 AM
Points: 2,882, Visits: 3,324

Thanks for all your comments.

I wrote this article is kind of sacrasm.  I did a lot of projects, most of the projects had talented team of programmers working on it.  It failed because of the management did not understand the extent of the project or lack of communication between the users and the project leaders.

Every time something liked this happened, I was upset, I worked 60 to 70 hours a week on a project and it failed because of poor management, poor project definition and poor communication.   However when the project failed, management blamed it to the programmers, I had enough of this and that was the reason why I wrote this article.  

It did not mean I was not responsible for the project, it just meant sometimes I could not control a lot of situation that caused it to fail.

This is the main theme of the article !!!

Have a nice day.

Post #361947
Posted Monday, April 30, 2007 7:13 AM


Group: General Forum Members
Last Login: Friday, June 18, 2010 7:36 AM
Points: 15, Visits: 5


This is a really good article and it reflects the thoughts going on in the minds of developers who have been working day and night on projects which ultimately are deemed as the failure by the management. So whose fault is it? The management or business users never accept that it is because of them the project has failed. So ultimately the poor developers are to take the blame.

I totally agree that the key to the success of the project is the satisafaction of all the stakeholders in the project. But though the project is a failure, the coders/programmers have some satisafaction to the extent that they have done their part with responsibility but the project failed because of something which is not in their hands.

Kudos to the author..

Good day..

Post #361950
Posted Monday, April 30, 2007 7:13 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, September 6, 2016 1:49 PM
Points: 361, Visits: 443
From The Article: Communication failed and I am sure that as a result, the HMO users felt, at least to some extent, that the project had failed. So who failed, when the people who need to talk to each other don't?

Sarcasm or not, this is where you should have made the effort to talk to the end users and get them to make an additional request to IT to have the doctors grouped for them. Even if a percentage of the doctors were grouped by IT based, it would have made the project a more successful. The end users would then see that IT was working with them and not against them.

I did not see this article as sarcasm. I see it as a developer doing ONLY development and not taking the extra step or steps to understand the business rules and politics of the companies she worked at.


Post #361951
Posted Monday, April 30, 2007 7:54 AM



Group: General Forum Members
Last Login: Wednesday, April 27, 2016 9:47 AM
Points: 153, Visits: 579

You know, it's a funny world we live in.

If success is measured by whether you have a job or not, then the writer is a success. She has been involved in numerous projects that were useless or counter-productive to her clients, yet she seems to keep finding work!

I guess she is a success!

There seems to be a lot of what the Irish call "blarney" going on in the computer field. My Jewish friends call it "Chutspah". It happens in upper management, middle management, no management, and here in the developer arena. I learned a long time ago that the world is full of people who don't produce anything useful, but they still get jobs. You just have to do your best to work around them if you want to keep yours!

“Politicians are like diapers. They both need changing regularly and for the same reason.”
Post #361970
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse