April 13, 2016 at 10:42 pm
Comments posted to this topic are about the item Successful Projects
April 14, 2016 at 1:21 am
'Sometimes I think the problems in software development aren't that we write poor code, but rather that we rush a complex endeavor'
I think our code is getting better and better so I agree with the statement.
But also, the users' expectations are getting higher and higher so the complexity of the projects is growing exponentially.
Features we could only dream of 5 years ago are considered base requirements today.
April 14, 2016 at 3:35 am
The most important criteria for me is the active and positive support of all stakeholders. Especially users, management and implementers.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
April 14, 2016 at 6:42 am
I see an endless series of interruptions for the new project to fix, retrofit, enhance, just simply maintain the ever growing amount of existing code for our in-house software package that steals time away from that new development. That never seems to be calculated properly into the mix so everything new is always late from some arbitrary deadline set by management.
April 14, 2016 at 7:02 am
Interative development with a series of deliverable milestones. I've found that stakeholders and users are more willing to accept long (and even expensive) project lifecycles, if they can get their hands on usable deliverables at predicatable intervals. It establishes trust in the development team and allows the ogranization to start getting a return on their investment early on. IT development projects where team members sit in isolated cubicles and hack out code that won't see the light of day for a year, two years, or three: That's like the Dark Ages. We're more like in the Age Of Enlightenment now, at least for those who are willing to embrace it.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
April 14, 2016 at 7:10 am
"9. Do you have too many concurrent tasks?"
This is my major issue. Too many completing projects, no time, no resources. When I ask for assistance, I'm told, "It's job security". :angry:
April 14, 2016 at 8:35 am
Good article, but I wonder if the answer to what makes a successful project isn't complicated. I've been in my current job a little over a year. I've yet to see any project come to completion. Sometimes that's political (e.g.: there's some managers who don't want to sign off on any project being completed, even after all the stated work is done. I don't know why, they just don't). In most cases I just haven't been here long enough to see any project completed, because they're multi-year projects. I work in state government and something that is a guiding principle is that any project must have the phrase "requirements" in it somewhere. This precludes most agile project management, since most of those don't use the word "requirements". (I've been told the reason why its important to State government is because auditors need to see that word "requirements" somewhere. You don't have that, then the project is DOA.) So, what makes a project successful? Depends upon the company/agency doing the project.
Kindest Regards, Rod Connect with me on LinkedIn.
April 14, 2016 at 9:39 am
The amazing thing is how much value gets created when this works.
412-977-3526 call/text
April 14, 2016 at 10:49 am
From the Article:
Sometimes I think the problems in software development aren't that we write poor code, but rather that we rush a complex endeavor, being willing to redo work rather than proceeding in a more engineered fashion.
I think that pretty much sums a large part of the problem. The more succinct version of that statement is "They wanted it real bad... and that's the way they got it"!!! 😛
The other half to three quarters of the time, it's Developers and DBAs that don't actually know how to get the current date and time. 😉 The translation there is that a lot of people don't have the time to do it right the first time because they have to spend too much time trying to figure out how to do it at all. It would be interesting to find out what percentage of the world's programmers rely on forums like SSC to actually do their job (sorry, have the job done for them). :sick:
--Jeff Moden
Change is inevitable... Change for the better is not.
April 14, 2016 at 12:24 pm
I've spent a lot of time analysing project failures.
It boils down to breakdowns in communication and failure to check that communication has been successful.
Requirements are given and received. Both parties confirm independently that they share a common understanding of those requirements but fail to collaborate to check that they have a shared understanding.
There are so many different ways to fail
April 14, 2016 at 1:20 pm
Kick-off Meeting - that's the one important meeting in any project. It is where all the parties gauge their expectations.
and you said this:
Sometimes I think the problems in software development aren't that we write poor code, but rather that we rush a complex endeavor, being willing to redo work rather than proceeding in a more engineered fashion.
Is this a criticism to Agile development? This is the strength of the Waterfall model.
SQL Server Database Administrator
April 14, 2016 at 1:36 pm
While technical failures are important, you want to make sure the projects make financial sense as well.
Perhaps we should be asking, could you sell or implement a project that only met the requirements.
412-977-3526 call/text
April 14, 2016 at 2:01 pm
The "Joel Test" in Steve's link is right on target for the Project Leader. I work at a software development company and we always succeed in our projects, on time and on budget. Much of that is due to the expertise of the analysts and project leads.
I would add my own list for DBAs and Developers. Hopefully they all work at an abstract level where they are never doing "custom" designs or thinking about actual detail values.
1. Are you using the workflow items from the Joel Test?
2. Are you using proven application frameworks?
3. Are you using solid design patterns?
4. Are you using templates for all common tasks?
5. Are you using standard operating procedures?
6. Are you including quality checks for each task you perform?
7. Are you continuously improving each process?
8. Have you developed tools to automate most of your work?
These are standard engineering approaches to reduce variability and use commodity parts to produce new inventions. I've heard the ipod was made with commodity items even though it was supposedly a futuristic invention.
April 14, 2016 at 2:46 pm
Jeff Moden (4/14/2016)
...would be interesting to find out what percentage of the world's programmers rely on forums like SSC to actually do their job (sorry, have the job done for them). :sick:
I keep having to suggest that giving a specific issue, as opposed to requirement, would be more likely to invoke a response.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
April 14, 2016 at 8:18 pm
MarlonRibunal (4/14/2016)
Kick-off Meeting - that's the one important meeting in any project. It is where all the parties gauge their expectations.and you said this:
Sometimes I think the problems in software development aren't that we write poor code, but rather that we rush a complex endeavor, being willing to redo work rather than proceeding in a more engineered fashion.
Is this a criticism to Agile development? This is the strength of the Waterfall model.
Not at all. Agile isn't about just coding whatever. Many of the successful projects are engineered well, with thought about what they will do, and won't do, in a sprint. If you try to treat Agile like it's just a meeting every 2-3 weeks to check progress, it fails.
Waterfall fails, IMHO, because we can't get enough of the details and specs up front. Clients don't know, and we don't know what to ask. Things come up in development.
Agile works well by proceeding at a pace that does x amount of work, in a short period of time. The work is still architected and well thought out, there's just less of it before we re-start the next sprint.
Viewing 15 posts - 1 through 15 (of 31 total)
You must be logged in to reply to this topic. Login to reply