An initial step in developing a software project is to set aside a scope and an outline for the tasks to be carried out. The actual test of the software capabilities starts after these initial steps. Irrespective of the size of the software project, the initial warnings of its failure can be well judged. The symptoms can be loud and clear if the projects are small. However, larger projects often require great introspection for any failure detection. In a broader way, few signs of failures can be felt common across all software projects. Some of them are given below.
1) Working in concurrency
A rule in Software Project Management says that, no two works should be carried concurrently in the initial phases of a software development. Software coders and Business Analysts play their roles during these stages. Their works have to be separated and performed as different entities. Coding must always succeed requirement gathering stage and not vice versa. Often, it is found among many teams that coding starts even while analysts are busy gathering the requirements from the work givers. This happens with a notion that changes can be made to the developed codes, as and when the requirements are changed. This is actually a first step for failure among many software projects.
2) Size and technology to be used
A correct procedure to follow is to hire the project workers once the requirement gathering has been completed and validated. This ensures that the right numbers of people are working in the team. A large team size not only increases the budget but also can create unnecessary confusion. Another aspect to be considered is the type of technology to be used in the application. For this, the actual budget allocated for the project has to be borne in mind and an appropriate decision has to be taken. If the size of the team and technology used are inappropriate, you can be rest assured in software not clicking.
3) Piling up of requirements
It is necessary that all the documents gathered be simple, short and covering all the requirements of the client. If more than the required docs are gathered, it will not just be cumbersome in handling them but also there will be a possibility of the coder missing few details. Collecting over requirements can thus prove as a warning for an early failure of software.
4) Ignorance
Encountering bugs and other related failures is nothing new in the software development process. If they are ignored or are taken lightly, the issue can get complicated and difficult to handle.
5) Outsourcing
In most projects, there will certain tasks that can be worked upon remotely. These tasks could either be complicated or time consuming. In any case, outsourcing the work or a part of it can be considered as a warning of failure of the software in the later stages.
6) Participation blues
At any stage of software project development, if senior management or participants avoid attending meetings or block communication channels, then the chances of collapse of project is very high. This is often considered as most dangerous warnings of all.
In Software Project Management
Many independent developers have the problem of procrastinating on getting started on their own software projects because they don't know where to start or which idea to work on. A flurry of indecision and uncertainty or desire for instant gratification tangles up their brain and they can't seem to get started.
At least for myself, I've noticed several things. The first is in relation to whether I'm procrastinating because there's something I'd prefer to do (e.g. play a game) or simply because the work is boring with no immediate result in sight.
If it's the former, then you simply have to try and remove the distraction from being something that is actually able to distract you. Uninstall that game. Put the TV in the basement. Whatever it takes. For me, after about two years of repeated failures due to constantly following the path of instant gratification, my brain eventually began to associate playing games with lack of financial success and lack of a social life. As a result, I barely play games at all now, and when I do, it's not for very long because I feel unfulfilled by doing so.
Now if you're in the latter category, where the work is combination of being too boring or too big, then you can probably solve this by creating a snowball effect for yourself. The trick here is to get all of your masses of ideas, list them all down and prioritise them according to how much you've already done, how much they're likely to make and how quickly you can get them finished so they can make some money for you. In this case it's very important to take into account 37 Signals' mantra of building a simple product with only a small set of features. Start the software small and have it do the core job well. You can always improve it later.
Now that you have a big list, you're going to find that you've released some of the indecision in your head about what to work because of the fact that you've stored your idea in a safe place for when you're ready to tackle it, and no longer have any fear that if you don't do it now you'll forget about it. Pick the idea that will generate you enough revenue to live on, or at least work part time, and is the quickest to implement, and move it to the top of the list. EVERYTHING else goes on the backburner. Most importantly, make sure you've chosen something that can be completed within a short space of time (1 to 3 months) so that you can see it taking shape quickly. This will keep you motivated.
If you're a visual person, start mocking up the user interface. This will get your creative juices flowing without having to strain your brain trying to figure out where to begin coding. Also, by having a mockup in front of you, it'll force you to think about design issues and how you're going to tackle certain things that the user has to do. Once you have fleshed out your user interface, you'll also have a good idea of what you should start on, plus you'll be motivated because you'll feel like you've gotten a start on your product.
If you're NOT a visual person, start out by writing a list of features you'd like to have. Write out your goal for what you'd like your software to do and get a basic scratchy design happening. I think if you're the sole developer and your product isn't too complex, you can get away with something simple. You don't really need complex design specs. Just make sure you have a good understanding of what it is you're trying to do. One thing I've found when doing this, is that the fact of starting to write down in point form what it is that I want to do means that I start automatically coming up with extra ideas, or refinements to the idea I came with originally. Once you have a good list of points down and have cut out all the things you don't need in your first release, you'll have a good idea of what you need to start coding.
The moral of the story is:
1) Eliminate distractions which help you procrastinate
2) Stash all your ideas in a safe place so you can clear them out of your head, and concentrate on one idea.
3) Get creative and do a little written or visual design work to help you flesh out your product more thoroughly 4) Use the results of #3 to get you started on your coding.
Both Musa Aykac & Nathan Ridley are contributors for EditorialToday. The above articles have been edited for relevancy and timeliness. All write-ups, reviews, tips and guides published by EditorialToday.com and its partners or affiliates are for informational purposes only. They should not be used for any legal or any other type of advice. We do not endorse any author, contributor, writer or article posted by our team.
Nathan Ridley has sinced written about articles on various topics from . . Nathan Ridley's top article generates over 6600 views. Bookmark Nathan Ridley to your Favourites.
Carl Jung Analytical Psychology But the majority and the heart of Jungs clinical career was taken up with what we might call today individual psychodynamic psychotherapy, in gross structure very much in the strain of psychoanalyti...