|
Try to, anyways. Depends on the pressure from mgmt and the bu and other activities I've got going on. As I always say, there is a price to pay for everything. I've been on projects where I've cut out meetings, interactions with the business unit, and adequate testing just to meet a deadline. The price is the rework and future maintenance of the product.
|
|
|
|
|
Either that, or "I plead the 5th..."
The best way to improve Windows is run it on a Mac.
The best way to bring a Mac to its knees is to run Windows on it.
~ my brother Jeff
|
|
|
|
|
If you think your job is done at that point then you are creating a whole lot of problems for yourself (and the rest of us).
|
|
|
|
|
I have been in software and systems development since the late 1970s. Both from an anecdotal perspective from my own experiences, and from my studies to get an MBA, the best approach, especially with agile, is to have a team leader that is a senior software engineer, with experience and knowledge in business so he or she can communicate as well with customers (internal or external) as with developers.
All members of the team should report directly to the Team Lead - BAs, QAs, app developers, and DB developers. There is only one driver's seat on the team bus. Working as a team is essential, but when leadership is needed, only one leader is optimum. And the team lead must take the arrows for the team so they can be productive and not get bogged down by external issues.
|
|
|
|
|
Basically we decide to work on whatever change requests are most important and when they're finished I get to say when we'll do a software release. Makes it easy to be on-time every time. 
|
|
|
|
|
At some places, the Business Analysts have risen up and hijacked the so-called "agile" team and they set priorities and dates - but have no expertise in software engineering nor the software development life cycle (SDLC). Dates are commonly missed because of their decisions, but they rarely take responsibility. I is truly sad to see how these places have BAs and QAs running the SDLC, but with little to no knowledge of how software engineering works. Developers, to them, are basically code monkeys.
|
|
|
|
|
Development and delivery. The actual 100% development is done in first 50% of the estimated time. user acceptance and getting out of the window with clients signature takes rest of the time.
|
|
|
|
|
The general pattern is this:
PM: We need this by Tuesday
Development: Okay, here you go
PM: When I asked for x, I actually meant y
Development: No worries - here's the new version
PM: Thanks. Oh, by the way, any chance we could have z?
Development: Yes, here you go.
PM: Cool. Now I come to think of it, could you just maybe tweak x so that it does something unrecognisable from the original x.
Development: But we weren't going with x, would you rather tweak y?
PM: No, forget that, let's redefine z
Development: Okay, z now does pretty much what x used to do
PM: Ah, that's good. Not sure we need it any more, though.
Development: Fine, it's on UAT if you change your mind.
[3 MONTHS LATER]
PM: Have we still got that thingymajig?
Development: Yes, it's still there on UAT.
PM: Cool. Can we get it live by next month?
Development: Yes, as long as you can get someone to test it.
PM: I'll get back to you on that. Did you ever manage to get it to make a cup of tea when it's done? I know we didn't ask for that but it would be a pretty nifty feature.
[2 YEARS LATER]
PM: We tested that software. We had to fail it, I'm afraid - we didn't get that cup of tea. The stuff it did do might have been right, I can't quite remember the requirement it was that long ago.
98.4% of statistics are made up on the spot.
|
|
|
|
|
Sounds like pretty much every damn project I've ever worked on. Sometimes I find it a miracle that any software ever gets out the door.
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."
-- Marcus Brigstocke, British Comedian
|
|
|
|
|
So true 
Patrice
“Everything should be made as simple as possible, but no simpler.” Albert Einstein
|
|
|
|
|
I have been programming professionally since 1978, and I could not agree more. Projects take on a life of their own, and those answering yes are kidding themselves. "Project Creep" and ridiculously vague "requirements" are the driving forces in my experience.  
It's a random chance Universe and we are all out there surfing waves of probability...
|
|
|
|
|
Although no deliver dates, I generally get it done faster than expected.
This, however, might be a result of the really lousy delivery record for any number of the overseas outsourced projects that take far too long and perform far too poorly.
A second caveat is that somehow I've been given a blank check with respect to which project I do when. Clarifying, I often have several sitting in line - I almost always make the decision of priorities (bug > new > tweak) - but that's not the whole story.
There's also (owner/very Sr. Mgmt > nice people > neutrals/new faces > ![Elephant | [mastadon]](https://www.codeproject.com/script/Forums/Images/elephant.gif) ass).
How this came about is a mystery - although making stuff that works correctly, for a long time, and is smoothly upgradable may have helped my cause.
The content of the two replies immediately before this Survey Results - Do you get your IT projects delivered on time?[^] and Survey Results - Do you get your IT projects delivered on time?[^] also are part of it.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
And the secret to that is to establish a reputation as a miracle worker: pad your time estimates so you can deliver early ... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Every one uses that same strat. 
I am not the one who knocks. I never knock.
In fact, I hate knocking.
|
|
|
|
|
All of our projects are internal. Presently our only delay is getting the users to complete UAT and regression.
So any delays that happen now are not due to use delivering late. 
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
Simon_Whale wrote: All of our projects are internal. Presently our only delay is getting the users to complete UAT and regression.
So any delays that happen now are not due to use delivering late.
That is true for most of my work at the present time. However, it doesn't stop the user/customer from claiming the project was delivered behind schedule. They just leave out the part where it took them 3 weeks to even get around to testing, then decided that a feature they forgot to mention should be considered a "bug" because it wasn't included.
|
|
|
|
|
I hear you on that one, but then the parent company mentored our department a bit and now the people that make decisions have to sit around the table every 2 weeks and let the project sponsor know why it's late.
and the project sponsor is senior figure and for our main application it is run by our General Manager, who is also a divisional head in the parent company, so the waffle is then removed
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
