Why Do Software Development Projects Fail?
Вставка
- Опубліковано 28 чер 2023
- What are some reasons why custom software projects fail? What should we avoid when building a custom application? How do we ensure success for our project? These are the questions we will answer in today's episode of Dev Questions.
Website: www.iamtimcorey.com/
Ask Your Question: suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: signup.iamtimcorey.com/
![Why Projects Fail [5 PROJECT FAILURE CAUSES]](/img/n.gif)
"Tools and techniques, don't replace good projet management" Gold!
Thanks!
To use a tool, you must be able to do it without a tool. You just simplify your life with the tool.
If you describe a tool with "here, some magic happens ..." something is wrong.
It does not apply to latest AI-tools, but that's the exception today anyway.
I was literally on a call 2 hours ago where a project was basing research into packages, scope, approach, everything off of an assumption of how the user wanted it because 'he's not available on calls, he's too busy'. An hour of my time saying repeatedly 'well we can't plan this then, because we don't actually know what they want'. Could've done without that.
I commented above without getting to your thread, been there and use the above tactic - works like a charm. And there is no body in my company that will veto the way I handle it, because I get results with hard to deal with clients as they reply. If they don't then the project is a bust so why waste your time trying to guess what they want, as the end of the day they will say that's not what I wanted.
Yep, it happens a lot.
Wow. I can speak from personal experience that you are absolutely right. I've had some epic fails and I pretty much made all the mistakes you mention. Thanks for summarizing the pitfalls so well so that I can more easily remember them for the future!
Thanks for sharing!
Yes I admit of being guilty of feature creep and being hurraoptimistic about the schedule :D. Precisely written requirements is an absolute gold. The person who understands bits of programmers and the business is also an amazing support. Cheers thanks for great analysis.
You are welcome.
Very nicely done. Im guilty of a lot of these. I’m an SQL Developer. For me the biggest headache is not getting the details the user. And a good PM is an absolute must.
When dealing with users ask them questions, if there's no one there to ask then pause the project and let them know the reason. They never fail to get in contact after that conversation, and all of a sudden they get all talkative. The main reason for lack of direction is that they are looking out for their own job, and if they are too specific and the project goes wrong only they are to blame. Whereas if they lump it on to you they have their escape route.
Thanks for sharing!
thanks Tim. You are my best motivator for work.
You are welcome.
Having/being a PM that can sit between the users and development that actually understand both sides can make things so much more likely to succeed. Knowing the lingo of both sides and translating back and forth in meetings, dragging out the requirements and concerns. bi-directional communications. Restating assumptions back to the other side as they are made. When I was acting as a PM We would be in meetings and while planning V1 I would be pushing things out to V2 and V3 vocally so everyone understood how things had to happen. It helped everyone visualize and set expectations that things take time.
Thanks for sharing!
Thanks. Curiosity question. In some meetings did you have people representing the users and people representing the programmers who write the code. If so, during the first meeting, did you explain the rules of conduct to be adopted between them for the project to move forward?
@@lebeluet Yes, all sides were present. We had worked together for some time so it was always casual, no formal rules were needed. Keeping meetings not too large helps. You do not need 20 people representing any role. Just a well informed few who can speak for their roles. Having worked closely also allowed us to be able to convert more easily convert from user desires tech speak. Restating things back to the 'users' helps a LOT to clarify these situations. It needs to be treated as a collaborative effort.
I would imagine with some companies egos can become a problem. Fortunately I never had that in these situations, well, just mine. ;)
Managers: " Why not " 😅
Yep.
Tim do you actually use TDD in a daily basis or just when it makes sense. I mean when your building a business crud app that saves to a database, is it really necessary to use TDD. I can understand if there was some heavy logic in between but to write tests to perform crud or other basic functions never really appealed to me.
I don't typically follow TDD. I take a bit more of a pragmatic approach. I write tests as I feel I need them rather than trying to write the tests first for everything I do.
@@IAmTimCorey I agree.. I wonder how many companies actually do this in the real world and if they do it, if its "just because" they want to follow some sort of practice.
Hi, first I would like to thank you for what are you doing and providing in this channel. Second, I want to ask you about how much we need of solving problems to start web dev with asp and other tools and frameworks?
Software development in general is all about solving problems. That's what we do. Practicing those skills and getting better at solving problems and applying logic is what will turn you into a great developer.
What do you think about risk plans? A list of risks and mitigation strategies. Do you think they are useful/ essential too?
Like with just about everything, they can be if done well with the right purpose in mind. The key is to know WHY you are doing a risk plan. If it is because you have to in order to check off a box, you are doing it wrong. You need to develop a simple plan that identifies the major risks (not minor ones) and develops a clear plan on how to mitigate them. The risk plan should be clean and simple. If it is pages of plans and contingencies, it has become its own risk.
I hate feature creep. At my day job it's decently easy. I they start asking for things beyond the scope of the ticket they created I just tell them to create another ticket and someone will get to it. My manager backs us completely on things like this. As far as my side work I'll take a look and estimate time involved and then let the customer know their "quote" just went up because I quoted you for a specific thing... any extra needs more money :)
Thanks for sharing!
Am on my third failed project, this time we succeeded in shipping but the users claim they prefer the manual way, apparently the AI shd be doing everything...
Sorry to hear that.
I'm my own feature creep
We all have been at some point.
A lot of software projects are dead in the water for no technical reasons at all, the main culprit is that business moves fast and zig-zags when new information is discovered.
"We need customer portal because competitor A has one".
Six months later...
"Oh, we forgot to tell you, we found out that our competitors customers HATED dealing through a portal, but we have a new project for you...our competitor has an automated inventory system"
Projects should:
1. Deal with the main pain points of the business.
2. Those pain points should be *say* 5 years old and *say* $100M to the red.
Then you will get support instead of backlash with Tim's 9 points.
I think having a clear vision of the future rather than trying to follow competitors.
"I love weekend projects; They last about a month" - Tim Corey🤣
I just had a discussion about a new "weekend project" with a team member. They reminded me of this statement...again.
Uno platform T-shirt ❤
👍
You have to allow for feature creep. Think about it. The alternative is delivering something the client doesn't want. This particular feature might have become critical to the client's whole business, so who are you to say they can't have it? This is *soft*ware, remember. Soft. Not hard. Easy to change. If it can't be changed, then you have a bad design.
As you did identify, though, there is a trade-off between the richness of the application and the duration of development, but it is the developer's responsibility to convey that to their line manager/the client/whichever applies. Nothing more. They certainly don't have the right to say, "you can't have that", That is for the client to choose.
I disagree, but we may be closer than it initially appears. Feature/scope creep is one of the biggest causes for project failure. You seem to be operating under the principle that those additional features are necessary. That may be the case, but are they necessary now? That's the key question. If they are absolutely necessary now, you need to basically restart the project process. You pause what you are doing, go back to the planning phase and discuss how that feature works, etc. and then figure out what that will do to impact the overall timeline and budget. Only then do you restart development with the new critical feature as part of the process. An example of this might be that you are building a house and you forgot to add doors. That's critical. So, you figure out where doors should go and figure out how much more money it will cost in labor and materials, and then you get back to building. That isn't feature creep, that's addressing a major mistake in your initial design.
However, that's not a common issue. What is much more common is when the customer comes to you and says "I need X feature as well" and it isn't actually necessary to have that feature day one. That is when you say "great, we will add that to version 1.1" and you continue on building version 1. Then you discuss how much it will cost to add that new feature now that the initial application is complete. Because as you said, your software should be easy to change so changing later shouldn't be an issue.
The problem a lot of software developers get into is saying "I'm going to need to add this feature later anyway so I'll add it now". That stretches out the development process and it increases the amount of time it takes to get the software out the door and into the customers' hands. That is dangerous for a number of reasons.
As for the developer being able to say "you can't have that", it does depend on the chain of command a bit, but the developer needs to communicate reality. If you are "just a developer" and have no control over budget, etc. then you should still be able to communicate reality. For instance, if a feature is going to take 20 hours to complete and they want an additional change to the feature that will take an additional 10 hours, the developer absolutely needs to be able to communicate that. You should be able to say "I can't do that in the original 20 hours". Essentially, "you can't have that for the original budget".
@@IAmTimCorey I take your point and it's certainly reasonable to say "you can't have that for the initial budget". In fact I think it's our duty to point that out. Broadly, a task that expands to twice its original size will take twice the effort, that's basically just Archimedes. But I maintain that it's the developer's responsibility to make sure they know that, but ultimately it's their call.
I gotta say that sensible clients, in my experience, will do what you say "that'd do for v2" etc. There's some planning going on, for sure. But also in my experience, they ain't all sensible :) I find I'm far better at spotting the duff ones as I've gotten older.
Good, fast, cheap... Pick 2
Yep
Because they spent too much time listening to Tim's videos and not enough time programming.
lol
Programming quality does not increase with time invested.
@@holger_p bullshit take anyone off of the street and say create me any app. 99.9 won’t know what to do, get them to invest a little time and we get another Tim Corey. You are so dumb