Rule #3 Trashing=Bad Processing

Well-defined development processes are important and necessary elements of software project survival (McConell, 1997).

McConell just said so, processes are a fundamental  in the software development, a ✌🏻good tip✌🏻 is making a schedule of the processes you’re going to do in the lifetime of the project.


Plan and fail at it, is the best way to learn to plan. At the beginning of the project you don’t know how big the project is going to be, maybe it’s going to take 5 weeks or 30 weeks, you will never know. Anyways, a good practice is to do the project in two parts, first get an idea of what you’re going to do, play around with the ideas and get a demo, in order to get approbation from the client/project owner and get a better idea of what are going to do, there is not recepe when you talk about project managing. using git is cool, if you use it in a good way, controlling the versions of your project, not by uploading everything in  a last single commit, you should better use google drive for storing in that case.


The deffiniton of working, but what you do, does not contribute to the project, if trashing is 90% of your time, then the project will not work at all, if you have a well-defined process, the software personnel can spend their work on productive stuff, and not in trashing (basically), but if you don’t have any plan, it’s going to be a hell of mistakes that will make even more mistakes that can be a critical factor in the success, processes shouldn’t be viewed as rigid steps, because when a project .



What’s wrong with that table? It’s a waste of time for a developer.captura-de-pantalla-2017-02-01-15-58-02

no advance at the beginning, it is gonna be a TOTAL FAILURE. avoid this kind of projects.



Rule #2 Test yourself

How do you know if your project is working as expected? , well, almost all skills that exist on earth can be measured with a test, it is a good way to understand your project progress. The test provided by McConell will help you to understand the shape of the project, whether is going to fail or not. it is important to be realistic and don’t lie to yourself, since is extremely important to have realistic goals, this can even help to find strengths in the project to work with.




The test is available in the next link:

Rule #1: Survive

Everybody is talking a lot about the survival training on topics related to the project management, but why? is it really so necessary to take any kind of training? you might say, “of course”, and you’ll be right, because it is good to have a direction before starting a project, it helps us to avoid losing tons of money or getting fire, it is a reality that from 300,000 software projects in the USA, between  1/3 and 2/3 of those projects will exceed their schedule and budget targets before they are delivered (McConnell, S. 1997). So yes, it is an importantopic indeed, and in software community, the users might complain a lot about the release dates and functionalities of the software, but the failure is always (or most of the times) avoidable with the right planning, anyways the manager must be in charge of the continuity of the project and prevent the cancelation from the client. This course will be like going to a camp, but, a Project Survival Training Camp. Before starting anything, the temas must follow the principal rules, or in this case, the rights (just like people, projects tent to have right and obligations too), and some rights must be satisfied in order to continue with an effective and well focus project and the rights must be required for everybody that works on the project without discrimination, having a productive environment is one of them, making everybody follow the rights will made the chances of survival bigger.



McConell, S. (1997). Software Project Survival Guide. United States: Microsoft Pres.